我什么时候应该创建一个新的 DbContext()

Question

我目前正在使用类似于此的DbContext：

namespace Models
{
    public class ContextDB: DbContext
    {
              
        public DbSet<User> Users { get; set; }
        public DbSet<UserRole> UserRoles { get; set; }

        public ContextDB()
        {
            
        }
    }
}

然后，我在需要访问数据库的 ALL 我的控制器顶部使用以下行。我还在我的 UserRepository 类中使​​用它，其中包含与用户相关的所有方法（例如获取活动用户、检查他的角色等）：

ContextDB _db = new ContextDB();

考虑到这一点，有时一个访问者可以激活多个 DbContext，例如，如果它正在访问使用 UserRepository 的控制器，这可能不是最好的想法。

我应该什么时候创建一个新的 DbContext？或者，我是否应该有一个在所有地方传递和重用的全局上下文？这会导致性能下降吗？也欢迎提出替代方法的建议。

Answer 1

我使用了一个基础控制器，它公开了一个派生控制器可以访问的DataBase 属性。

public abstract class BaseController : Controller
{
    public BaseController()
    {
        Database = new DatabaseContext();
    }

    protected DatabaseContext Database { get; set; }

    protected override void Dispose(bool disposing)
    {
        Database.Dispose();
        base.Dispose(disposing);
    }
}

我的应用程序中的所有控制器都派生自BaseController，并按如下方式使用：

public class UserController : BaseController
{
    [HttpGet]
    public ActionResult Index()
    {
        return View(Database.Users.OrderBy(p => p.Name).ToList());
    }
}

现在回答你的问题：

我什么时候应该创建一个新的 DbContext / 我应该有一个全局上下文 我路过吗？

应根据请求创建上下文。创建上下文，做你需要做的事情然后摆脱它。使用我使用的基类解决方案，您只需要担心使用上下文。

不要尝试拥有全局上下文（这不是 Web 应用程序的工作方式）。

我能否拥有一个可以在所有地方重复使用的全局上下文？

不，如果您保留上下文，它将跟踪所有更新、添加、删除等，这会减慢您的应用程序速度，甚至可能导致一些非常微妙的错误出现在您的应用程序中。

您可能应该选择将您的存储库或您的上下文公开给您的控制器，但不能同时公开。如果两个上下文对应用程序的当前状态有不同的想法，那么从同一个方法访问两个上下文将会导致错误。

就我个人而言，我更喜欢直接公开DbContext，因为我见过的大多数存储库示例最终都只是围绕DbContext 进行了精简包装。

这会影响性能吗？

第一次创建DbContext 非常昂贵，但是一旦完成，就会缓存很多信息，以便后续实例化更快。与每次需要访问数据库时实例化一个上下文相比，您更有可能看到保持上下文的性能问题。

其他人是怎么做到的？

视情况而定。

有些人更喜欢使用依赖注入框架在创建时将其上下文的具体实例传递给他们的控制器。两种选择都很好。我的更适合小型应用程序，您知道正在使用的特定数据库不会改变。

有些人可能会争辩说您无法知道这一点，这就是依赖注入方法更好的原因，因为它使您的应用程序对更改更具弹性。我对此的看法是，它可能不会改变（SQL 服务器和实体框架几乎不晦涩），而且我的时间最好花在编写特定于我的应用程序的代码上。

Answer 2

我尝试根据自己的经验来回答。

1.我应该什么时候创建一个新的 DbContext / 我应该有一个可以传递的全局上下文？

Context 应该通过依赖注入来注入，而不应该自己实例化。最佳实践是通过依赖注入将其创建为范围服务。 （见我对问题 4 的回答）

还请考虑使用适当的分层应用程序结构，例如 Controller > BusinessLogic > Repository。在这种情况下，您的控制器不会接收 db-context 而是接收存储库。在控制器中注入/实例化 db-context 告诉我，您的应用程序架构在一个地方混合了许多职责，在任何情况下，我都不推荐。

2。我可以拥有一个可以在所有地方重复使用的全局上下文吗？

是的，您可以拥有，但问题应该是“应该我拥有...” -> 否。上下文旨在用于每个请求以更改您的存储库，然后再次离开。

3.这会导致性能下降吗？

是的，因为 DBContext 根本不是为了全局而设计的。它存储所有已输入或查询到的数据，直到它被销毁。这意味着全局上下文将变得越来越大，对其的操作将变得越来越慢，直到您遇到内存不足异常或您因年龄增长而死去，因为这一切都变慢了。

当多个线程同时访问同一个上下文时，您也会遇到异常和许多错误。

4.其他人是怎么做到的？

工厂通过依赖注入注入的DBContext；范围：

services.AddDbContext<UserDbContext>(o => o.UseSqlServer(this.settings.DatabaseOptions.UserDBConnectionString));

希望我的回答对你有帮助。

Answer 3

从性能的角度来看，DbContext 应该在实际需要时创建 just，例如，当您需要在业务层内拥有用户列表时，您可以从 DbContext 和 创建一个实例immediately dispose 当你的工作完成时它​​p>

using(var context=new DbContex())
{
var users=context.Users.Where(x=>x.ClassId==4).ToList();

}

context 实例将在离开Using 块后被处置。

但是如果你不立即释放它会发生什么？
DbContext本质上是一个缓存，你查询的越多，占用的内存块就越多。
如果 concurrent requests 向您的应用程序泛滥，这将更加明显，在这种情况下，您占用内存块的每一毫秒都至关重要，更不用说一秒钟了。
您越推迟处理不必要的对象，您的应用程序就越容易崩溃！

当然，在某些情况下，您需要保留您的 DbContext 实例并在代码的另一部分使用它，但在同一 Request Context 中。

我推荐您访问以下链接以获取有关管理 DbContext 的更多信息：
dbcontext Scope

Answer 4

现在我正在尝试这种方法，它可以避免在调用不使用它的操作时实例化上下文。

public abstract class BaseController : Controller
{
    public BaseController() { }

    private DatabaseContext _database;
    protected DatabaseContext Database
    {
        get
        {
            if (_database == null)
                _database = new DatabaseContext();
            return _database;
        }
    }

    protected override void Dispose(bool disposing)
    {
        if (_database != null)
            _database.Dispose();
        base.Dispose(disposing);
    }
}

Answer 5

您应该在每次 Save() 操作后立即释放上下文。否则每次后续保存都需要更长的时间。我有一个项目在一个循环中创建和保存复杂的数据库实体。令我惊讶的是，在循环中移动“using (var ctx = new MyContext()){...}”后，操作速度提高了三倍。

Answer 6

这显然是一个较老的问题，但是如果您使用 DI，您可以执行类似的操作并将所有对象的范围限定为请求的生命周期

 public class UnitOfWorkAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuting(HttpActionContext actionContext)
        {
            var context = IoC.CurrentNestedContainer.GetInstance<DatabaseContext>();
            context.BeginTransaction();
        }

        public override void OnActionExecuted(HttpActionExecutedContext actionContext)
        {
            var context = IoC.CurrentNestedContainer.GetInstance<DatabaseContext>();
            context.CloseTransaction(actionContext.Exception);
        }
    }