NHibernateユーザープログラマーが犯す最も一般的な間違いとアンチパターンは何ですか？それらが悪い習慣である理由を説明するか、さらに読むためにリソースへのリンクを提供してください。
例えば：
回答:
私の個人的な「よく説明される」問題：
DTOを使用する代わりに、切り離されたオブジェクト（SaveOrUpdateまたはMergeといくつかの乱雑なコード）をいじります。エンティティが複雑になるほど、コードはより複雑になります。（それはまた、些細なエンティティで非常にうまく機能することを意味します。）Ayendeはまた、ストリッパーパターンと呼び、カプセル化の問題を説明します。
明示的なSQLを使用する場合のように、永続性の無知を理解せず、NHアプリケーションを記述しません。その症状：オブジェクトを変更した後にUpdateを呼び出す、Updateが呼び出されていなくても変更が永続化される理由、および変更が永続化されるのを回避する方法を疑問に思う。
トランザクションと作業単位のパターンを理解していない。頻繁なアンチパターン：暗黙的なトランザクション、操作ごとのセッション、アプリケーションごとのセッション。もっと読む：
NH イベントを使用してアプリケーションロジックを挿入する（たとえば、挿入および更新トリガーの変更追跡）
テーブルごとに1つのクラスを作成します。OODを理解していない人もいれば、リレーショナルデザインを理解していない人もいます。
使用1対1の代わりに、多対1。この答えで説明しようとしました。
使用すると、フェッチ参加 SetMaxResultとの組み合わせで。そのトピックに関連する私の最新の回答：
ライティング自己変更エンティティを。エンティティがNHによって設定された値を正確に返さない場合、そのエンティティはダーティと見なされ、すべてのセッションで更新されます。たとえば、プロパティセッターのNH永続コレクションを置き換えます。
IList<Address> Addresses
{
get { return addresses; }
// will cause the addresses collection to be built up from scratch
// in the database in every session, even when just reading the entity.
set { addresses = new List<Address>(value); }
}
int Whatever
{
// will make the entity dirty after reading negative values from the db.
// this causes unexpected updates after just reading the entity.
get { if (whatever < 0) return 0; }
set { whatever = value; }
}
もっと続くかもしれません。
これは、すべてのエンティティとその属性の単一選択ではなく、操作する各エンティティの選択（N）と、エンティティのリストを取得する選択（+1）を実行する場所です。
FluentNHibernate後からEntity Framework（または他の何か）に切り替えることができるように、抽象化しようとします。
これは、それを実現しようとするほとんどの人よりもはるかに困難です。両者の間には多くの違いがあり、時には微妙な場合もあります。また、最終的に実際に必要になることは非常にまれです-あなたのアプローチがすべて間違っていることを発見する前に、何年も細心の注意を払って実装しようとすることができるほどです。
また、2次キャッシュ、インターセプト、同時実行管理、変更追跡、プリフェッチクエリなど、NHibernateの便利で重要な機能を使用することを制限します。
実際にNHibernateとEntity Frameworkを切り替える必要がある場合は、GitHub（おそらくCommonServiceLocatorと似たようなもの）でこれをサポートするために、多数の貢献者とプルリクエストで積極的に開発されたプロジェクトがあります。