Ninject.MVC构造函数注入其中注入对象的构造函数采用参数

Question

您好我正在使用Ninject.MVC Nuget包与我的MVC3应用程序，我有一些构造函数注入的当前绑定设置。

private static void RegisterServices(IKernel kernel) 
    { 
     kernel.Bind<IUnitOfWork>().To<ERSUnitOfWork>(); 
     kernel.Bind<IRepository<Recipe>>().To<GenericRepository<Recipe>>(); 
    } 

我控制器例子如下：

public class RecipesController : Controller 
{ 
    private readonly IUnitOfWork unitOfWork; 
    private readonly ERSDbContext context; 
    private readonly IRepository<Recipe> recipeRepository; 

    public RecipesController(IUnitOfWork unitOfWork, IRepository<Recipe> recipeRepository) 
    { 
     this.context = new ERSDbContext(); 
     this.unitOfWork = unitOfWork; 
     this.recipeRepository = recipeRepository; 
    } 
} 

我想从控制器中删除私有的DbContext财产和通过新的ERSDbContext（）来ERSUnitOfWork和GenericRepository的构造为部分Ninject正在执行的构造函数注入，但最好在控制器内部保持ERSDbContext类的初始化？

任何帮助你如何做到这一点将不胜感激。谢谢

我有点希望它不需要我的NinjectWebCommon类必须创建DbContext，我想要在控制器中初始化。

Answer 1

这是你如何抽象你的依赖关系的问题。

因为你想拥有，当你创建你DbContext例如在控制，你应该有一个工厂，将创建特定类型的DbContext情况下，像这样：

public interface IDbContextFactory 
{ 
    T CreateDbContext<T>() where T : DbContext; 
} 

_{（请注意，如果您的DI框架处理类型参数的通用接口上还算不错，那么你可以用IDbContextFactory interface去，将其与实体框架5）}

介绍如果你永远只需要创建一个广告类型DbContext实例EFAULT，参数构造函数，你可以定义你的界面，如下所示：

public interface IDbContextFactory 
{ 
    T CreateDbContext<T>() where T : DbContext, new(); 
} 

，然后定义像这样实现：

public class DbContextFactory : IDbContextFactory 
{ 

    #region Implementation of IDbContextFactory 

    public T CreateDbContext<T>() where T : DbContext, new() 
    { 
     // Create a new instance of T and return. 
     return new T(); 
    } 

    #endregion 
} 

如果需要调用不同的构造函数，那么你删除new() constraint并且必须使用反射调用（或者，您可以创建一个lambda表达式并根据T的类型对其进行高速缓存）以创建键入的DbContext。

从那里您将IDbContextFactory合同与您的实施相关联，并将IDbContextFactory实施注入您的课程，就像您将使用其他任何接口一样。

Answer 2

这是依赖注入的好处之一，它会自动解析所有构造函数参数及其相关的构造函数参数。它为你做了这一切，只需要定义对象的映射。

所以你的情况，你只是这样做：

kerel.Bind<ERSDbContext>().ToSelf(); 

然后，你可以添加ERSDbContext您UOW和回购，你是好。

如果你想单元测试的东西，那么你就需要抽象的背景下不知何故，无论是作为casperOne提到或我提到（其中你让你的DbContext从通用接口派生），然后做到这一点，而不是：

kernel.Bind<IDbContext>().To<ERSDbContext>(); 

使用DI的好处之一是它控制对象的生命周期。如果您将DbContext的构建推迟到DI容器的外部，那么您必须手动管理其生命周期，而不是允许DI容器根据生命周期策略（例如在请求结束时自动销毁它）来管理它。

我认为延迟创建上下文没有任何可衡量的好处。我认为你正在做过早的优化。

Answer 3

由于我的并发问题，我暂时取消了工厂的使用，而我正在使用这种方法，因为我的时间很短。

kernel.Bind<ERSDbContext>().ToSelf().InRequestScope(); 

然后在我的UoW和GenericRepository中构造函数需要一个ERSDbContext类型参数。

我想稍后改进这种方法，但现在这工作。