构造函数依赖地狱

Question

我尝试使用尽可能多的接口来进行良好的单元测试并更好地理解程序架构。

尽管我尝试遵循 SOLID 规则 - 我的类需要在构造函数中传递大量依赖项，这变成了地狱。

搜索使我找到了 IoC 容器，但实际上我不太了解何时使用它们。在构造函数中传递一个 NInject 内核看起来是一个愚蠢的想法，并且只使用 NInject 创建主类并不能消除构造函数中一堆参数的问题。

我无法减少构造函数中的依赖数量。我不明白如何正确使用 NInject 来减少构造函数参数。我该如何解决这个问题？

（不是最坏的例子）

public SomeConstructor(ISettings settings, INotification notification, IServer server, IPriceCache priceCache)
{
    Settings = settings;
    Notification = notificartion;
    Server = server;
    PriceCache = priceCache;
}

（这个解决方案看起来很糟糕）

public SomeConstructor(IKernel ninjectKernel)
{
    Settings = ninjectKernel.Get<ISettings>();
    Notification = ninjectKernel.Get<INotification>();
    Server = ninjectKernel.Get<IServer>();
    PriceCache = ninjectKernel.Get<IPriceCache>();
}

Answer 1

使用 IoC / DI 的原因之一是摆脱生命周期责任 - 即组件应该 请求 依赖项（通过例如构造函数注入或属性注入），但不应该拥有他们。

因此，应该有一些其他类，通常称为某种类型的 container，它管理生命周期范围和依赖关系。

在（理想的）组织良好的架构中，您永远不会为服务调用解析 - 您在容器中注册所有服务，并让它们存活 - 然后容器将为它们创建组件并解决必要的依赖关系（维护创建和处置，当必要的，在不同的生命周期范围内）。

所以你做的几乎所有事情都“正确”，但只是缺少这个“容器”概念。

Answer 2

如果你不想要构造函数中的任何东西，那么Ninject 允许你通过使用属性来使用名为Property Setter Injection 的东西。它看起来像这样：

class Samurai 
{    
    [Inject]
    public IWeapon Weapon { private get; set; }

    public void Attack(string target) 
    {
        this.Weapon.Hit(target);
    }
}

但正如我在上面的评论中提到的。所有这些基本上都是一样的，只是因为你没有在你的构造函数中包含项目并不会改变你觉得你的代码有大量依赖项的事实。