Ninject是否确保及时清理和处置我的DbContext？
按照这个答案：
CLR文档指出，创建Disposable对象的任何人都应负责调用Dispose。在这种情况下，对象是由Ninject创建的。这意味着您不应显式调用Dispose。
Ninject处置具有另一个作用域的每个Disposable对象，而不是
InTransientScope
在GC收集与创建的对象相关联的作用域对象后立即进行处理。这就是为什么每个Disposable对象都应该是Bindd且作用域不是InTransientScope（）的原因。例如，您可以使用NamedScope
扩展中的
InParentScope（），一旦注入到对象中的对象被垃圾回收，它将立即处理该对象。
我为所有应用程序的控制器创建了一个基类，以处理任何常见的初始化等。该基类在构造函数中接受我的DbContext参数的实例。但这要求我也将此参数添加到应用程序中的每个控制器。有什么方法可以不需要这个吗？
简而言之， 切勿 对MVC
Controller使用通用的基类。类继承倾向于紧密地耦合您的逻辑，并且随着时间的推移将变得难以维护。它还会导致您创建God对象，因为创建多个级别的注入依赖项将意味着每个Controller需要更多的依赖项。
如果您有横切关注点，则应改用全局注册的过滤器。您可以为每个逻辑块创建一个单独的过滤器，这不会像共享基类那样违反单一职责原则。而且，如果您在全局范围内注册过滤器，则可以在此操作过滤器或此授权过滤器中使用构造函数注入。您还可以设置自己的属性（不带行为），以根据需要根据控制器和/或操作来设置它们的条件。
例：
由于您明确表示要
ViewBag基于当前用户设置通用属性，因此可以使用过滤器执行以下操作。
CurrentUserProfileFilter
public class CurrentUserProfileFilter : IAuthorizationFilter{ private readonly MyDbContext context; public CurrentUserAuthorizationFilter(MyDbContext context) { this.context = context; } public void onAuthorization(AuthorizationContext filterContext) { var currentUserName = filterContext.HttpContext.User.Identity.Name; // Set the ViewBag for the request. filterContext.Controller.ViewBag.UserName = currentUserName; var userBirthdate = from user as this.context.AspNetUsers where user.UserName == currentUserName select birthdate; if (userBirthdate.Date == DateTime.Now.Date) { filterContext.Controller.ViewBag.Message = "Happy Birthday!"; } }}GlobalFilterProvider
MVC具有静态功能
GlobalFiltersCollection，您应该在其中静态注册全局过滤器实例。对于具有依赖项且生命周期由DI容器管理的依赖关系的过滤器（例如
DbContext），将不会执行此操作。
为了确保按需解析过滤器（按请求），我们
IFilterProvider将通过容器进行解析（假设您的Ninject容器已在MVC中注册为DependencyResolver）；
public class GlobalFilterProvider : IFilterProvider{ private readonly IDependencyResolver dependencyResolver; public GlobalFilterProvider(IDependencyResolver dependencyResolver) { this.dependencyResolver = dependencyResolver; } public IEnumerable<Filter> GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor) { foreach (var filter in this.dependencyResolver.GetServices<IActionFilter>()) { yield return new Filter(filter, FilterScope.Global, order: null); } foreach (var filter in this.dependencyResolver.GetServices<IAuthorizationFilter>()) { yield return new Filter(filter, FilterScope.Global, order: null); } foreach (var filter in this.dependencyResolver.GetServices<IExceptionFilter>()) { yield return new Filter(filter, FilterScope.Global, order: null); } foreach (var filter in this.dependencyResolver.GetServices<IResultFilter>()) { yield return new Filter(filter, FilterScope.Global, order: null); } // If MVC 5, add these as well... //foreach (var filter in this.dependencyResolver.GetServices<System.Web.Mvc.Filters.IAuthenticationFilter>()) //{ // yield return new Filter(filter, FilterScope.Global, order: null); //} }}用法
在您的Ninject合成根目录中，使用所
kernel实现的过滤器接口的类型注册过滤器的实例。
// Self-bind our filter, so dependencies can be injected.kernel.Bind<IAuthorizationFilter>().To<CurrentUserProfileFilter>();
在中
FilterConfig，注册您的过滤器提供商。
public class FilterConfig{ public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new HandleErrorAttribute()); // Register the filter provider with MVC. FilterProviders.Providers.Insert(0, new GlobalFilterProvider(DependencyResolver.Current)); }}现在，根据每个请求，将填充您的用户详细信息。
但更重要的是，您
ArticlesController不需要
MyDbContext作为依赖项，其他控制器也不需要。
我不确定创建DbContext实例的成本是多少。有什么方法可以使优化仅在请求实际上需要我访问数据库时才创建。
看一下这个问题：每个Web请求一个DbContext
…为什么？
