我理解并接受身份生成器会破坏工作单元，因为它需要在事务实际提交时进行插入，如 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 模式，或者它是否有不同的方式来处理这个问题，如果是的话，它是什么？
最佳答案
我不会确切地告诉你为什么 NHibernate 中不延迟插入，但我猜想 NHibernate 只是在你将其放入 session 时立即需要真实的实体标识。
EF 没有使用这种方法，但这并不意味着 EF 方法更好。首先，EF 没有内置对身份生成器的支持。您可以implement your own但仅仅因为 NH 试图避免的问题，这可能会有点具有挑战性。
ORM 工具实现身份映射，并且要求每个实体都被唯一标识。 NH 可能会立即使用真实身份，而 EF 可以推迟身份定义并使用一些临时 key 。当在数据库中定义真实身份时，将使用此临时 key - 这意味着 MS SQL Server 中的 IDENTITY 列。只有在向数据库插入记录并查询SCOPE_IDENTIY()后，EF 才知道真实身份。当 EF 收到真实 key 时，它会更新实体及其所有关系 (FK) 以反射(reflect)真实身份。
这也是该方法的最大缺点 - EF 必须在数据库的单独往返中插入每条记录才能获取其主键值(EF 无论如何都不支持命令批处理)。在这里，您会发现与 NH 的最大区别，NH 能够使用生成器预生成身份并将这些 DML 命令批处理到数据库的单次往返。
当您开始使用 EF 4.0 中引入的 FK 属性时，在 EF 中使用临时键会产生另一个副作用。使用 FK 属性后，您必须显式将 PK 设置为某个唯一的临时值，否则插入具有关系的两条记录将失败并出现异常(您将拥有两个具有默认键值的实体，并且 FK 属性将无法定义哪一个是正确的主体)。
EF 旨在使用数据库生成的 key ，而 NH 更喜欢应用程序生成的 key 。
关于entity-framework - 为什么身份生成器会破坏 nHibernate 中的工作单元？那么EF呢？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11413537/