Question

在构建在其数据访问层中使用实体框架的Web应用程序时，建议从对象上下文中分离对象以允许对象进行垃圾回收。

但由于网络应用程序都是请求 - ＆gt;响应应用程序，在将响应发送给客户之后，对象上下文本身不再被任何活动对象引用，因此对象上下文及其附加对象应该可用于垃圾收集，因为没有活动对象引用任何他们。

在这种情况下，我是否遗漏了某些内容或分离了不必要的对象？

Answer 1

我怀疑您所看到的指导是在谈论无跟踪查询

否 - 跟踪查询肯定会为读取密集型网站带来一些性能优势。

对象从不连接，并按身份进行跟踪，因此您无需分离它们，这样可以避免在实现过程中进行身份解析的成本。

无跟踪查询如下所示：

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

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

没有跟踪查询比手动分离实体有另一个好处：手动分离会断开实体与其实体Graph的其余部分的连接，在没有跟踪查询的情况下，您可以检索已分离的连接的连接图。

但是使用非跟踪查询也存在一些缺点： 由于您已关闭身份解析，因此偶尔会出现读取重复结果的情况。

因此，除非您确信您的查询只返回每个实体的一个副本，否则您应该小心，否则您可能会遇到UI错误。

希望这有帮助

亚历

PS：这tip on ObjectContext lifetime可能会对您有所帮助。

Answer 2

穆罕默德，我不能和EF说话，但由于它与Linq-to-SQL有关，因此分离对象与垃圾收集没有任何关系。它与从数据库上下文中分离对象有关，因此可以将其附加到另一个对象。这在无状态（n层）应用程序中是非常常见的事情。这同样适用于EF。

兰迪

Answer 3

This article可能对您有所帮助。 EF的设计类似于NHibernate，默认情况下具有有状态会话/上下文（即Windows窗体应用程序）。从版本1开始，这可能已经发生了变化，这是我上次查看它时的情况。这有点奇怪，因为大多数人都会将它用于网站 - 很像NHibernate会让你使用每个请求的会话，而不是主要考虑网站设计。

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

Answer 4

在EF中，如果必须使用多个上下文（如n层应用程序中），或者如果要创建entityCollection，则需要分离实体。但这不是asp.net应用程序的严格实现

Answer 5

假设你没有保持对象上下文（以某种方式保持对它的引用），一旦它超出范围，它将被垃圾收集。我看不出需要分离实体。

所以，我认为你没有遗漏任何东西。

实体框架和deataching对象

5 个答案: