entity-framework - 在 ASP.NET MVC Controller 中管理 Entity Framework ObjectContext 依赖注入(inject)的正确方法是什么？

Question

在我的 MVC Controller 中，我使用的是 IoC 容器(Ninject)，但不确定如何最好地使用 Entity Framework ObjectContext。

目前，我正在做类似的事情:

using(var context = new MyObjectContext())
{
     var stuff = m_repository.GetStuff(context);
}

从尽可能短的时间内保持数据库连接打开的角度来看，这是最好的管理方式。

如果我要根据每个请求通过 Ninject 创建 ObjectContext，这显然会使数据库连接打开太久。

上面的代码也会变成......

var stuff = m_repository.GetStuff(m_myObjectContext);

(我什么时候处理上下文......？)

我应该为 ObjectContext 创建一个工厂并通过 DI 传递它吗？这会放松耦合，但是如果没有简单的方法来维护 ObjectContext 的接口(interface)(我知道)，这真的有助于可测试性吗？

有没有更好的办法？谢谢

Answer 1

This is the best way to manage from the point of view of keeping the database connection open for the shortest time possible.

If I were to create the ObjectContext via Ninject on a per request basis, this obviously keeps the database connection open for too long.

Entity Framework 将在执行每个查询后直接关闭连接(除非从外部提供打开的连接)，因此您执行此类操作的论点不成立。

过去，我曾经通过业务逻辑(准确地说是我的 command handlers)控制上下文(创建、提交和处置)，但缺点是您需要将此上下文传递给所有其他方法和所有依赖项。当应用程序逻辑变得更复杂时，这会导致代码的可读性和可维护性降低。

出于这个原因，我转向了一个模型，其中工作单元(您的 MyObjectContext)是在业务逻辑控制之外创建、提交和处置的。这允许您将工作单元注入(inject)所有依赖项并为所有对象重用相同的工作单元。缺点是这会使您的 DI 配置更加困难。您需要确保的一些事项:

必须根据 Web 请求或在一定范围内创建工作单元。

工作单元必须在请求或作用域的末尾进行处理(尽管 DbContext 未处理时可能不是问题，因为下划线连接已关闭且 DbContext 未实现终结器)。

您需要明确提交工作单元，但您不能在 Web 请求结束时执行此操作，因为此时您不知道提交是否安全(因为您不想提交业务逻辑抛出异常，但在请求结束时无法正确检测这是否真的发生)。

我可以给您的一个提示是围绕 command handlers 对系统中的业务逻辑进行建模。 ，因为这允许您在单个点定义一个处理事务行为(提交工作单元，甚至可能运行数据库事务中的所有内容)的单个装饰器。这个装饰器可以包裹在系统中的每个处理程序周围。

我必须承认我不知道如何使用 Ninject 注册泛型类型和泛型装饰器，但是当您在 Stackoverflow 上提问时，您可能会很快得到答案。