最近采取的步骤将 Ninject 合并到 MVC 应用程序中并将 DbContext 引入到控制器的构造函数中，自然会出现某些问题出现：
Ninject 是否保证清理并及时处置我的 DbContext实例？
正如此响应中所述：
根据 CLR 文档，Disposable 对象的创建者负责调用 Dispose，在本例中为 Ninject。因此，不鼓励显式调用 Dispose。
一旦 GC 收集到它们所绑定的范围对象，Ninject 就会在 InTransientScope() 之外的任何范围内处置 Disposable 对象。因此，所有 Disposable 对象都应使用不是 InTransientScope() 的范围进行绑定。
消除在每个控制器中包含 DbContext 参数的要求是否可行？
完全避免使用 MVC 控制器的共享基类。类继承促进了紧密耦合并妨碍了可维护性。此外，它往往会创建“上帝对象”，从而需要每个控制器进一步依赖。
或者，考虑利用全局注册的过滤器来处理横切关注点。您可以为不同的逻辑组件设计特定的过滤器，遵守单一职责原则，共享基类会违反这一原则。通过全局注册它们，您可以使用构造函数注入，甚至可以为控制器和/或操作级别的条件应用程序创建属性（无行为）。
如何优化 DbContext 实例的创建？
请参阅以下问题以获取见解：[每个 Web 请求一个 DbContext...为什么？](https://stackoverflow.com/questions/9155198/one-dbcontext-per-web-request-why)
以上是Ninject 和 DbContext：确保正确处置并优化实例创建？的详细内容。更多信息请关注PHP中文网其他相关文章！
