构造函数依赖注入的基类 [英] Constructor Dependency Injection in Base Class

问题描述

我要建实体框架的存储库的基类，所有实体存储库将继承。我想用用Ninject依赖注入在基类中注入 DatabaseContext 。我认为，构造函数注入是正确的做法，但我这样做与构造函数注入在派生类将必须通过参数的构造函数的基类，我不希望它。因此，Setter注入是比较合适的？

下面是我的code：

 公共抽象类BaseRepository＆LT; TEntity＆GT; ：IDisposable接口
    其中，TEntity：类
{
    私人只读DatabaseContext _databaseContext;

    保护BaseRepository（DatabaseContext databaseContext）
    {
        this._databaseContext = databaseContext;
    }
}
 

在上面的例子中使用构造函数注入，我在派生类中我将必须通过databaseContext对象的基类，我不喜欢这样做是为了我的所有的派生类：

 公共类UsuarioRepository：BaseRepository＆LT; IUsuario＆gt;中
    IUsuarioRepository
{
    公共UsuarioRepository（DatabaseContext databaseContext）
        ：基地（databaseContext）
    {
    }
}
 

Setter注入，而不是构造函数注入是解决的好办法？什么是最好的方法是什么？

更新：

使用Setter注入我的派生类的不会有构造函数：

 公共类UsuarioRepository：BaseRepository＆LT; IUsuario＆gt;中IUsuarioRepository
{
}
 

我的上下文是唯一一个在所有的应用程序。我不需要派生类传递上下文对象，但我喜欢在基类中注入它在未来的使用嘲笑做检查。

我解决这个问题：

对不起，我困惑的问题，但我解决我的问题，建设一个工厂：

 公共抽象类BaseRepository＆LT; TEntity＆GT; ：IBaseRepository＆LT; TEntity＆GT;
   其中，TEntity：类
{
    私人只读ContextFactory _contextFactory =新ContextFactory（）;

    保护DatabaseContext CurrentContext
    {
        得到
        {
            返回this._contextFactory.GetCurrentContext（）;
        }
    }
 }
 

和我的派生类将看起来像：

 公共类UsuarioRepository：BaseRepository＆LT; IUsuario＆gt;中IUsuarioRepository
{
}
 

和我厂这样的：

 公共类ContextFactory
{
    公共DatabaseContext GetCurrentContext（）
    {
        返回新DatabaseContext（）;
    }
}
 

解决方案

属性注入暗示的依赖是可选的，而构造器注入意味着依赖是必需的。选择相应的模式。

在95％以上的情况下的构造的注射液是正确的图案。什么是你不喜欢？

i'm building a repository base class with Entity Framework where all Entities repository will inherit. I want to inject the DatabaseContext in base class using Dependency Injection using Ninject. I think the Constructor Injection is the right way, but doing this with Constructor Injection in derived class I will must to pass parameter to constructor in base class and I don't want it. Therefore, a Setter Injection is more appropriate?

Here's my code:

public abstract class BaseRepository<TEntity> : IDisposable 
    where TEntity : class
{
    private readonly DatabaseContext _databaseContext;

    protected BaseRepository(DatabaseContext databaseContext)
    {
        this._databaseContext = databaseContext;
    }
}

Using Constructor Injection in the above example, in my derived class I will must to pass databaseContext object to base class, I don't like to doing this to all my derived class:

public class UsuarioRepository : BaseRepository<IUsuario>,
    IUsuarioRepository
{
    public UsuarioRepository(DatabaseContext databaseContext)
        : base(databaseContext)
    {
    }
}

Setter Injection instead of Constructor Injection is a good way to solve that? What is the best way?

Update:

Using Setter Injection my derived class's will not have constructors:

public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository
{
}

My Context is only one in all application. I don't need derived class to pass context object, but i like to inject it in base class to using mocks for tests in future.

I Solve the problem:

Sorry, I'm confusing with the question, but i'm solving my problem building a Factory:

public abstract class BaseRepository<TEntity> : IBaseRepository<TEntity>
   where TEntity : class
{
    private readonly ContextFactory _contextFactory = new ContextFactory();

    protected DatabaseContext CurrentContext
    {
        get
        {
            return this._contextFactory.GetCurrentContext();
        }
    }
 }

And my derived class will look like that:

public class UsuarioRepository : BaseRepository<IUsuario>, IUsuarioRepository
{
}

And My Factory like that:

public class ContextFactory
{
    public DatabaseContext GetCurrentContext()
    {
        return new DatabaseContext();
    }
}

解决方案

Property Injection implies that the dependency is optional, while Constructor Injection implies that the dependency is required. Choose a pattern accordingly.

In more than 95% of the cases Constructor Injection is the correct pattern. What about it don't you like?

这篇关于构造函数依赖注入的基类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！