实体框架和分离对象

我怀疑你看到的指导是说没有跟踪问题

对于阅读密集型网站,没有跟踪查询绝对具有一些性能优势。

对象是 从未 附加的,并由身份跟踪,所以您不需要分离它们,这避免了在物化过程中进行身份解析的成本。

无跟踪查询如下所示:

var source = ctx.Staff;
source.MergeOption == MergeOption.NoTracking;

var staff = (from s in source
             where s.ID == 12 
             select s).First();

与手动分离实体相比,没有跟踪查询还有另一个好处:手动分离将断开实体与其实体图的其余部分的连接,因为在没有跟踪查询的情况下,可以检索所有分离的已连接实体图。

但是使用非跟踪查询也有一些缺点: 有时,您可能会在阅读重复结果的情况下结束,因为您关闭了身份解析。

因此,除非您真的确信您的查询只会返回每个实体的一个副本,否则您应该小心,否则最终可能会出现UI错误。

希望这有帮助

亚历克斯

PS:这个 tip on ObjectContext lifetime 可能对你有帮助。

穆罕默德,我不能和ef说话,但因为它与linq to sql有关,分离对象与垃圾收集没有任何关系。它必须从数据库上下文中分离一个对象,这样它才能附加到另一个对象。在无状态(n层)应用程序中,这是非常常见的事情。这同样适用于英孚。

兰迪

在EF中,如果必须使用多个上下文(如在n层应用程序中),或者如果要创建EntityCollection,则需要分离实体。但对于ASP.NET应用程序来说不是一个要求很高的实现

假设不保留对象上下文(以某种方式保留对它的引用),一旦它超出范围,它将被垃圾收集。我看不出任何分离实体的必要性。

所以,我不认为你错过了什么。

This article 可能会帮助你。默认情况下,ef的设计类似于nhibernate,具有状态会话/上下文(即Windows窗体应用程序)。这可能在我上次看第1版时发生了变化。不过,这有点奇怪,因为大多数人都会将它用于网站——就像NHibernate让您根据请求使用会话,而不是主要为网站设计的。

想法是你不必担心更新或插入,这一切都是自动为你完成的。这会增加内存使用量,但当应用程序正确管理它时,通常会提高性能而不是降低性能。