基类中的构造函数依赖注入

Question

我正在使用实体框架构建一个存储库基类，所有实体存储库都将继承该基类。我想使用 Ninject 使用依赖注入将 DatabaseContext 注入基类中。我认为构造函数注入是正确的方法，但是在派生类中使用构造函数注入执行此操作，我必须将参数传递给基类中的构造函数，但我不希望这样做。那么，Setter Injection 更合适吗？

这是我的代码：

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

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

在上面的示例中使用构造函数注入，在我的派生类中，我必须将 databaseContext 对象传递给基类，我不喜欢对所有派生类执行此操作：

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

Setter 注入而不是构造函数注入是解决这个问题的好方法？最好的方法是什么？

更新：

使用 Setter 注入，我的派生类将没有构造函数：

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

我的 Context 在所有应用程序中只有一个。我不需要派生类来传递上下文对象，但我喜欢将其注入基类中，以便将来使用模拟进行测试。

我解决了问题：

抱歉，我对这个问题感到困惑，但我正在解决构建工厂的问题：

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

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

我的派生类将如下所示：

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

而我的工厂将如下所示：

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

Answer 1

属性注入意味着依赖项是可选的，而构造函数注入意味着依赖项是必需的。相应地选择一种模式。

在超过 95% 的情况下，构造函数注入是正确的模式。你不喜欢又怎样？

Answer 2

我认为没有“最好的方法”。

构造函数和 setter 注入并不完全等同，因为 setter 注入为您提供了更多的灵活性。以下是我在两者之间进行选择的方法：

假设您创建了一个对象 A，而 A 需要一个 B 对象才能工作。要问的问题是：A 是否可以在没有与之关联的 B 的情况下存在/被实例化？ A 对象没有 B 是有效状态吗？有时，A 拥有 null B 是没有意义的，那么构造函数注入是更好的解决方案。如果 B 可以稍后分配给 A，而不一定是在构造时，那么就使用 setter 注入。所有这些都取决于您尝试建模的领域，并且答案会因情况而异。

Answer 3

真的，我看不出将参数传递给基类有任何问题。但如果这是绝对要求，您始终可以这样做：

public abstract class BaseRepository<TEntity> : IDisposable 
    where TEntity : class
{
    protected BaseRepository()
    {
    }

    protected abstract DatabaseContext GetContext();
}

现在您的派生类可以如下所示：

public class UsuarioRepository : BaseRepository<IUsuario>,
    IUsuarioRepository
{
    private DatabaseContext _databaseContext;

    public UsuarioRepository(DatabaseContext databaseContext)
    {
        _databaseContext = databaseContext;
    }

    protected override DatabaseContext GetContext()
    {
        return _databaseContext;
    }
}

现在您可以进行构造函数注入，而无需将参数传递给基本构造函数。但这确实是同一件事。

老实说，我不喜欢 setter 注入的想法，因为它看起来 DatabaseContext 是必需的依赖项。对于所需的依赖项，进行构造函数注入。如果它是可选的，那么无论如何，继续进行 setter 注入。
编辑

：

由于我们在评论中进行了长时间的对话，我对您想要完成的任务有了更好的理解。

如果您想将派生类与 DatabaseContext 解耦，最好以不同的方式进行设计。将派生类与其基类的依赖关系解耦是很困难的，如果您认为它们应该解耦，那么您将有更好的设计，根本不使用继承。

public class BaseRepository<TEntity> : IDisposable 
    where TEntity : class
{
    public BaseRepository(DatabaseContext context)
    {
    }
}

现在，您的派生类（将不再派生）将如下所示：

public class UsuarioRepository : IUsuarioRepository
{
    public UsuarioRepository(BaseRepository<IUsario> repository)
    {
    }

    // Implement other methods here
}

现在您可以拥有一个使用 DatabaseContext 的基类，并且您的派生类不再依赖于它。

Answer 4

1. 构造函数、2. Setter 和 3. 接口注入这三种方式各有优缺点，具体使用哪种方式取决于具体情况。如果我处于你的位置，我会选择 setter，尽管界面也可能是一个不错的选择。

请求您仔细阅读这篇文章
http://www.devx.com/dotnet/Article/34066