实体框架：不处理我的对象上下文会遇到什么负面影响？

Question

编辑：重复 Should Entity Framework Context be Put into Using Statement?

我一直在折腾这个想法一段时间，想知道如果不正确地处理我的对象上下文并让它随着 GC 而死，会发生什么坏事。通常，我会避免这样做，但这样做是有正当理由的。

我们正在使用部分类。在这些部分类中，我们公开了访问 FK 对象的属性。例如，假设我有一个带有 CustomerType FK 对象的 Customer 类。在课堂上，我会公开一个执行此操作的 CustomerTypeName 属性：

public string CustomerTypeName {
  get {
     if (CustomerType == null) {
         CustomerTypeReference.Load() 
     }

     return CustomerType.CustomerTypeName;
  }
}

如果原始查询没有执行 .Include("CustomerType")，这将非常方便。

但是，如果我处置上下文，上述属性将不再有效。所以......我想这会导致几个问题：

1) 如果我从不明确处理上下文，我会看到哪些负面影响（如果有的话）？
2）有没有其他方法可以在上述场景中完成延迟加载并且仍然处理上下文？

Answer 1

在我的answer 到 'LINQ to SQL - where does your DataContext live?' 中，我们将页面作为页面生命周期内 DataContext 的所有者，并且当页面本身被处理时，它是正确处理 DataContext 的页面。

正如@Chu 指出的那样，它有点脏，但是如果您要直接在 UI 中使用可以说是数据传输对象的东西，那么您的 UI 应该控制 DataContext 的生命周期。

Answer 2

只要您不继续加载/添加大量新对象，无限期保留的 ObjectContext 就可以了。

每个加载或添加的对象都会被 ObjectContext 跟踪，直到它被释放，所以如果你从不释放，并且继续跟踪更多的对象，它只会变得越来越大。

您可以考虑使用一些实用方法来访问一些众所周知的上下文或创建临时上下文。

关键是使用 EntityReference.EntityKey 并确保两个实体都是分离的。

即

this.CustomerType = Utility.GetDetachedObjectByKey<Customer>(
       this.CustomerTypeReference.EntityKey);

GetDetachedObjectByKey 的基本实现是这样的：

public static T GetDetachedObjectByKey<T>(EntityKey key) 
     where T: EntityObject
{
    using (MyContext ctx = new MyContext())
    {
        T t = ctx.GetObjectByKey(key) as T;
        ctx.Detach(t);
        return t;
    }
}

这仅在原始对象目标也被分离时才有效。你可以试验一下这个方法使用的 Context 是从哪里来的。

希望对你有帮助

亚历克斯

Answer 3

为什么不在屏幕的长度内保留上下文？