为什么身份生成器在nHibernate中断开工作单元？ EF怎么样？ [英] Why does identity generator break unit of work in nHibernate? What about EF?
问题描述
我理解并接受身份生成器打破工作单元，因为它需要在事务实际提交之前先插入，描述在 http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html 。我知道替代品，为什么他们更好（关于手头和一般的问题）。
我的问题是为什么实现存在以及这些问题是否影响EF（纯粹的好奇心）。我看到的唯一真正的理由是：NHibernate需要身份，因为会话中的每个实体（它们被称为持久实体）需要身份也通常用于确定记录是否已经存在于数据库中（未保存的值）。
为什么必须值吗？为什么它不会延迟INSERT，直到提交发生，提交，检索值，并更新依赖于返回的身份的实体，然后插入/更新/任何它们？
$ b $不重要的问题：EF是否遇到同样的问题？我知道ISession是一个正确的UoW实现; EF没有实现UoW模式，还是有不同的处理这个问题的方法，如果是这样，那么是什么？
我不会告诉你为什么插入在NHibernate中并没有被推迟，但是我猜当NHibernate把它放到会话时，只需要真正的实体身份。
EF不使用这种方法，但并不意味着EF方法更好。首先，EF没有内置对身份生成器的支持。您可以实现你自己的，但是由于NH想要避免的问题，这可能有点挑战。
ORM工具实现身份映射，他们要求每个实体被唯一标识。 NH可能立即使用真实身份，而EF可以延迟身份定义并使用一些临时密钥。当在数据库中定义真实身份时使用此临时密钥 - 这意味着MS SQL Server中的 IDENTITY 列。只有在将记录插入数据库并查询 SCOPE_IDENTIY（）之后，EF才会知道真实身份。当EF收到真实的密钥时，它更新实体及其所有关系（FK）以反映真实身份。
这也是方法的最大缺点 - EF必须将单独的往返中的每个记录插入数据库以获取其主键值（EF不支持命令批处理）。在这里，您可以发现与NH的最大区别是能够使用生成器预生成身份，并将这些DML命令批处理到单个往返数据库。
EF中临时密钥的使用有另一个开始使用EF 4.0中引入的FK属性时的副作用。一旦使用FK属性，您必须将PK显式设置为某个唯一的临时值，否则插入两个关系的记录将失败，并且异常（您将有两个具有默认键值的实体，FK属性将无法定义哪一个是正确的主体）
EF旨在使用数据库生成的密钥，而NH更喜欢应用程序生成的密钥。
I understand and accept that the identity generator breaks the unit of work because it requires an insert prior when the transaction should actually commit, described in http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html. I'm aware of the alternatives and why they are better (in relation to the problem at hand, and in general).
The question I have is why the implementation exists as it does, and whether or not these issues affect EF (sheer curiosity). The only real justification I have seen i: "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)."
Why must it have the value immediately, though? Why can it not defer the INSERT until the commit occurs, the commit, retrieve the value, and update the entities dependent on the returned identity, then insert/update/whatever them as well?
Less important question: does EF suffer from the same issue? I know ISession is a proper UoW implementation; does EF not implement the UoW pattern, or does it have a different way of handling this problem, and if so, what is it?
I will not tell you exactly why the insert is not deferred in NHibernate but I guess that NHibernate simply needs real entity identity immediately when you put it to the session.
EF doesn't use this approach but it doesn't mean that EF approach is better. First of all EF doesn't have built in support for identity generators. You can implement your own but it can be little bit challenging just because of issues NH is trying to avoid.
ORM tools implements identity map and they demand each entity to be uniquely identified. NH probably uses real identity immediately whereas EF can defer the identity definition and use some temporary key. This temporary key is used when the real identity is defined in the database - that means IDENTITY column in MS SQL Server. EF knows real identity only after inserting record to the database and querying SCOPE_IDENTIY(). When EF receives the real key it updates the entity and all its relations (FKs) to reflects the real identity.
This is also the biggest disadvantage of the approach - EF must insert every record in separate roundtrip to database to get its primary key value (EF doesn't support command batching anyway). Here you find the biggest difference with NH which is able to pregenerate identities using generators and batch those DML commands to single roundtrip to database.
Usage of temporary keys in EF has another side effects when you start using FK properties introduced in EF 4.0. Once FK properties are used you must explicitly set PK to some unique temporary value otherwise inserting two records with relations will fail with exception (you will have two entities with default key value and FK properties will not be able to define which one is a correct principal).
EF is designed to work with database generated keys whereas NH prefers application generated keys.
这篇关于为什么身份生成器在nHibernate中断开工作单元？ EF怎么样？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
