在LINQ to Entities中实例化上下文

我已经看到了程序员在代码中创建实体上下文时所采用的两种不同方式.

第一个是这样的,你可以在MSDN代码示例中找到它:

public void DoSomething() {
     using (TaxableEducationEntities context = new TaxableEducationEntities()) {
          // business logic and whatever else
     }
}

第二种是在一些封装了业务逻辑的类中将上下文创建为私有属性.所以你会有类似的东西:

public class Education_LINQ {

        private TaxableEducationEntities context = new TaxableEducationEntities();

        public void DoSomething() {
            var result = from a in context.luAction
                         select a;

            // business logic and whatever else
        }
}

哪种方式更有效？

假设您有两个方法,一个名为DoSomething1(),另一个名为DoSomething2(),两个方法都包含using语句来打开上下文并对其执行任何操作.你是否一个接一个地调用一个方法,是否会有任何多余的开销,因为基本上两个方法都创建了上下文,然后在它们完成后清理它？而不是只有一个私有属性在实例化类对象时创建,然后在对象超出范围时进行清理？

1> Alex James..：

---

每次创建一个新的ObjectContext确实涉及"一些"开销.实质上,所涉及的开销是将元数据从全局高速缓存复制到与特定ObjectContext相关联的元数据中.

这种开销相对较小,因此通常不值得担心,尤其是当您考虑使用模式中固有的额外安全性时.

对我来说,你选择哪个选项取决于:

你的包装课可能有多久了？如果它存在很长时间,ObjectContext可能会增长,以阻止许多实体随着时间的推移而减速.所以每次一个新的ObjectContext可能是一个好主意.

对包装类上的方法的调用是否同步？ObjectContext类本身不是线程安全的,所以如果你使用第二个模式,你需要确保你的包装类/存储库是线程安全的,如果你期望多个线程调用它.

方法基本上不相关吗？如果是这样,如果他们在方法之间共享一个上下文,则可能会出现意外的副作用.

一般来说,我的建议是,如果这些方法是无状态的,即火灾并忘记每种方法的新上下文可能是一个好主意.

但是,如果你有一个相对短暂的有状态形式或某些东西,那么共享上下文可能是一个更好的主意.

更新:我花时间整理了一个更完整的答案

---

博客文章的+1点http://blogs.msdn.com/alexj/archive/2009/05/07/tip-18-how-to-decide-on-a-lifetime-for-your-objectcontext.aspx

---

很好的问题,两个都很好的答案+1

---

那些在应用过滤器和排序的场景以及在服务层之上派生的层的情况怎么样？你应该预先实现数据,接受命中,并返回一个`IEnumerable`而不是`IQueryable`？您认为是否应该在服务层之外返回"IQueryable"？