EF（entity framework）使用“使用”语句
我有一个关于MVC的项目。 我们为数据库交易选择了EF。 我们为BLL层创建了一些管理器。 我找到了很多例子，其中using “ using ”语句，即
public Item GetItem(long itemId) { using (var db = new MyEntities()) { return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault(); } }
这里我们创建一个DBcontext MyEntities()的新实例。 我们使用“ using ”以“确保正确使用IDisposable对象”。
这只是我经理中的一种方法。 但我有十多个。 每当我从管理器调用任何方法时，我将使用“ using ”statemant并在内存中创建另一个DBcontext。 什么时候垃圾收集器（GC）会处理它们？ 谁知道？
但是还有另一种使用管理器方法的方法。 我们创建一个全局变量：
private readonly MyEntities db = new MyEntities();
并且在没有“ using ”语句的每个方法中使用DBcontext。 方法看起来像这样：
public Item GetItem(long itemId) { return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault(); }
问题：
- 使用DBcontext变量的正确方法是什么？
- 如果我们不使用“
usage”声明（因为它会影响性能）怎么办？GC会为此做些什么？
我是EF使用中的“新手”，但仍然没有找到这个问题的明确答案。
我想你会发现许多暗示这种风格的模式。 不只是我或Henk DBContext处理
- 是的，理想情况下使用DBContext子类型的语句
- 使用Using管理的更好的工作单元模式，具有上下文并处理上下文只是许多UoW示例中的一个，这个来自Tom Dykstra
- 每个Http请求都应该是新的工作单元管理器
- 上下文不是线程安全的，因此请确保每个线程都有自己的上下文。
- 让EF在幕后缓存东西。
- 测试上下文创建时间。 经过几次Http请求。 你还有顾虑吗？
- 如果将上下文存储在静态中，则会出现问题。 任何类型的并发访问都会受到影响，如果您使用并行AJAX调用，假设使用静态单个上下文时会出现90％以上的问题。
对于一些性能提示，非常值得一读
使用DBContext变量的正确或最佳实践方法是使用。
using (var db = new MyEntities()) { return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault(); }
好处是许多事情都是我们自动完成的。 例如，一旦完成代码块，就会调用dispose。
每个MSDN EF使用DbContext
上下文的生命周期在创建实例时开始，在实例处理或垃圾收集时结束。 如果您希望将上下文控制的所有资源放置在块的末尾，请使用。 使用时，编译器会自动创建一个try / finally块，并在finally块中调用dispose。