EF(实体框架)使用“；使用“；陈述

本文关键字：使用 陈述 实体 框架 EF | 更新日期: 2023-09-27 18:25:39

我有一个关于MVC的项目。我们为DB交易选择了EF。我们为BLL层创建了一些管理器。我发现了很多例子，其中使用了"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"语句，并在内存中创建另一个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();
}

问题：

  1. 使用DBcontext变量的正确方法是什么
  2. 如果我们不使用"usage"语句（因为它会影响性能），GC会为此做所有的事情，会怎么样

我是EF使用方面的"新手"，仍然没有找到这个问题的明确答案。

EF(实体框架)使用“；使用“；陈述

我想你会发现很多人建议使用这种模式。不仅仅是我或HenkDBContext处理

  • 是，理想情况下对DBContext子类型使用语句
  • 使用Using管理的更好的工作单元模式，有上下文并处理上下文只是许多UoW示例中的一个，这一个来自Tom Dykstra
  • 每个Http请求的工作单元管理器都应该是新的
  • 上下文不是线程安全的，所以请确保每个线程都有自己的上下文
  • 让EF缓存幕后的东西
  • 测试上下文创建时间。在几个Http请求之后。你还有顾虑吗
  • 如果将上下文存储在静态中，则会出现问题。任何类型的并发访问都会造成伤害，如果您使用并行AJAX调用，假设使用静态单个上下文时出现问题的可能性为90%以上

对于一些性能提示，值得一读

使用DBContext变量的正确或最佳做法是使用using。

    using (var db = new MyEntities())
    {
        return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
    }

好处是很多事情都是自动为我们完成的。例如，一旦代码块完成，就会调用dispose。

根据MSDN EF使用DbContext

上下文的生存期从创建实例时开始，并且当实例被释放或垃圾回收时结束。使用如果希望上下文控制的所有资源都是设置在块的末端。使用时，编译器自动创建try/finaly块，并在最后阻止。

相关文章：