为什么身份生成器会破坏 nHibernate 中的工作单元？英孚呢？

Question

我理解并接受身份生成器会破坏工作单元，因为它需要在事务实际提交时先进行插入，如http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html 中所述。我知道替代方案以及为什么它们更好（就手头的问题而言，以及总体而言）。

我的问题是为什么该实现存在，以及这些问题是否会影响 EF（纯粹是好奇）。我见过的唯一真正的理由是："NHibernate needs the identity because every entity in the session (they are called "persistent entities") needs to be identified. The identity is also normally used to determine if the record already exists in the database (unsaved value)."

为什么它必须立即具有价值呢？为什么它不能推迟 INSERT 直到提交发生，提交，检索值，并根据返回的身份更新实体，然后插入/更新/不管它们？

不太重要的问题：EF 是否遇到同样的问题？我知道 ISession 是一个合适的 UoW 实现； EF 没有实现 UoW 模式，还是有不同的方法来处理这个问题，如果有，是什么？

Answer 1

我不会确切地告诉你为什么 NHibernate 中没有延迟插入，但我猜 NHibernate 只是在你把它放到会话中时立即需要真实的实体身份。

EF 不使用这种方法，但这并不意味着 EF 方法更好。首先，EF 没有内置对身份生成器的支持。您可以implement your own，但由于 NH 试图避免的问题，这可能有点挑战性。

ORM 工具实现了身份映射，它们要求对每个实体进行唯一标识。 NH 可能立即使用真实身份，而 EF 可以推迟身份定义并使用一些临时密钥。当在数据库中定义真实身份时使用此临时键 - 这意味着 MS SQL Server 中的 IDENTITY 列。 EF 只有在将记录插入数据库并查询SCOPE_IDENTIY() 后才知道真实身份。当 EF 收到真实密钥时，它会更新实体及其所有关系 (FK) 以反映真实身份。

这也是该方法的最大缺点 - EF 必须在单独的往返中插入每条记录到数据库以获取其主键值（无论如何，EF 不支持命令批处理）。在这里你会发现 NH 最大的不同之处在于它能够使用生成器预生成身份并将这些 DML 命令批处理到单次往返数据库。

当您开始使用 EF 4.0 中引入的 FK 属性时，在 EF 中使用临时键会产生另一个副作用。一旦使用了 FK 属性，您必须将 PK 显式设置为某个唯一的临时值，否则插入两个具有关系的记录将失败并出现异常（您将有两个具有默认键值的实体，并且 FK 属性将无法定义哪个是正确的主体)。

EF 旨在使用数据库生成的密钥，而 NH 更喜欢应用程序生成的密钥。