c# - 将 DBContext 与依赖注入(inject)结合使用的后果

Question

我对在我正在编写的 ASP.NET MVC 应用程序中使用依赖注入(inject)来管理我的 DBContext 还是有点陌生​​。

我正在尝试遵循文章 Managing Entity Framework DbContext Lifetime in ASP.NET MVC 中概述的方法.基本上，这种方法表示使用 Ninject 和依赖项注入(inject)，并将我的 DBContext 作为参数添加到我的 Controller 中的构造函数。

此外，我正在一个基本 Controller 中实现它，或者我的所有 Controller 类都将派生。

这是可行的，但我遇到了以下问题。

1. 此方法要求每个派生 Controller 类还实现一个构造函数，该构造函数接受我的 Controller 基类所需的任何参数。这不仅看起来像是我必须记住添加到任何新派生类的大量额外类型，而且还意味着如果我更改传递给构造函数的数据，那么我必须修改每个派生 Controller 类中的构造函数。

2. 这为我的所有 Controller 类提供了一个 DBContext。但是我的模型中需要 DBContext 的其他类呢？我是否需要手动将实例传递给 DBContext 给所有这些类？或者有没有办法为这些类中的每一个使用 DI 来获取它们自己的 DBContext 副本？

Answer 1

This approach requires that every derived controller class also implements a constructor that accepts any arguments requires by my controller base class. Not only does this seem like a lot of extra typing that I must remember to add to any new derived class, but it also means that if I change the data passed to the constructor then I must modify the constructor in every derived controller class.

这是您可以选择在您的应用程序中使用 EF 的方法之一(重型 Controller )，IMO 它不是最干净的方法。而且您正确地注意到了自己的缺点。

如果我们将这种方法与设计原则联系起来，它会打破单一职责原则，因为 Controller 应该做更多的事情(获取或更新数据库)，而不仅仅是收集数据并返回包含数据的适当 View 。业务规则如何， Controller 会应用它，如果您需要发送电子邮件， Controller 也会这样做。您应该有另一层专门为一组需求设计的业务/服务类，例如EmailHelper 将发送电子邮件。

它也违反了开闭原则，因为每次更改输入参数时都需要更改构造函数。

This gives me a DBContext for all my controller classes. But what about other classes in my model that need the DBContext? Should I need to manually pass the instance to the DBContext to all these classes?

就依赖注入(inject)而言，目标之一是直接在需要的地方注入(inject)依赖。如果您有一个需要 DbContext 的模型类，您应该将它注入(inject)到您的模型类构造函数中(大多数 DI 框架也支持属性注入(inject)，但构造函数仍然是最喜欢的方法)。

使用 DI 框架，您将在一个地方(应用程序初始化代码)配置依赖项，然后每个需要依赖项的类只需在构造函数中接受它。

DI Container可以比作字典，key是interface，value是cooked object。设置完成后，您可以在整个应用程序中使用正确的 key 随时请求任何对象。

Or is there a way to use DI for each of these classes to get their own copy of the DBContext?

DI 框架支持不同的实例化方式，以允许控制实例的生命周期。通常，每个请求、每个线程和单例。更多信息 here .如果您希望每个 Controller 都获得 DbContext 的副本，则可以在设置 DbContext 实例化时使用每个请求配置。

替代解决方案:

我的大多数 MVC 应用程序都有一个服务层(一组应用业务规则的类)。这些类中的每一个都注入(inject)了 DbContext(不完全是 DbContext，而是 IDataContext)。 Controller 注入(inject)了它们检索或更新数据所需的服务类。

已经抽象出 IDataContext 背后的 DbContext，我可以在我的测试中设置一个 stub 数据上下文，或者明天如果我想从 EF 切换到 NHibernate 或更智能的 DI 框架，我将只需要实现 IDataContext 并更改依赖初始化代码。

希望这对您有所帮助。