NHibernate用户程序员最常犯的错误和反模式是什么？

NHibernate用户程序员最常犯的错误和反模式是什么？请解释为什么这些是不良做法，或提供指向资源的链接以供进一步阅读。

例如：

• 对于新的NHibernate程序员而言，一种常见的反模式是使用身份/本机POID代替ORM样式。在这里阅读更多...

我个人的“常见问题”问题：

反模式

与分离的对象（SaveOrUpdate或Merge以及一些凌乱的代码）混在一起，而不是使用DTO。实体越复杂，代码就越混乱。（这也意味着它可以与琐碎的实体很好地协同工作。）Ayende还将其称为“ 剥离器模式”，并解释了封装问题。

不像使用显式SQL那样理解持久性的无知并编写NH应用程序。症状：在更改对象后调用Update，想知道为什么即使未调用Update仍可以保留更改，想知道如何避免更改被保留。

• 我试图在这个SO答案中解释它
• 在参考文档中阅读冲洗的工作原理。
• 一个博客帖子由kurtharriger谁在指责什么实际上是一个主要特征（作为一个证明，它是关于NH一种常见的误解）

不了解交易和工作单位模式。频繁的反模式：隐式事务，每个操作会话和每个应用程序会话。更多阅读：

• Fabio Maulo：每笔业务交易的对话
• 在nhforge.org上：针对Web应用程序的有效NHibernate会话管理

使用NH 事件放置应用程序逻辑（例如，插入和更新触发器中的更改跟踪）

每个表创建一个类。有些人不了解OOD，另一些人不了解关系设计。

失误

使用一对一而不是多对一。我试图用它来解释这个答案。

将联合获取与SetMaxResult结合使用。我与该主题相关的最新答案：

• NHibernate为什么不急于获取我的数据（注释中有一些关于副作用的更多注释）
• 休眠-如何使协会渴望
• NHIbernate 1.2和延迟加载
• 使用Hibernate条件和FetchMode.JOIN分页

写自我改变的实体。当实体未完全返回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问题 ”。

在这里，您最终将对要操作的每个实体执行一次select（N），然后执行一次选择以获取实体列表（+1），而不是对所有实体及其属性进行一次选择。

• 太多抽象
• 不使用自动映射 FluentNHibernate

尝试对其进行抽象化，以便以后可以切换到Entity Framework（或其他方式）。

这比大多数尝试实现它的人要难得多。两者之间有许多差异，有时您可能会感到非常微妙。最终真正需要它的情况也很少见，因为它是如此之多，以至于您在发现自己的方法是完全错误的之前，可以认真尝试实施多年。

同样，它限制了您使用NHibernate的全部有用和重要功能，例如二级缓存，拦截，并发管理，更改跟踪，预取查询等。

如果确实有必要在NHibernate和Entity Framework之间进行切换，那么将有一个积极开发的项目在GitHub上支持此项目（也许与CommonServiceLocator相似），并且有许多贡献者和请求请求。