c# - 目录概念而不是复杂的构造函数？

Question

在我当前的项目中，我的经理强加了一些我想讨论的依赖注入(inject)设计概念，因为我很好奇依赖注入(inject)专家对这种方法的看法。这背后的想法是使用名为 catalog 的类，该类针对每个服务(Service Fabric 中的服务)实现，并在内部包含所有依赖项，如下所示:

public interface IDepA
{
}

public interface IDepB
{
}

public interface IDepC
{
}

public class StandardConstructorInjectorService
{
    private readonly IDepA _depA;
    private readonly IDepB _depB;
    private readonly IDepC _depC;

    public StandardConstructorInjectorService(IDepA depA, IDepB depB, IDepC depC)
    {
        _depA = depA;
        _depB = depB;
        _depC = depC;
    }
}

public class ServiceCatalog
{
    private readonly Container _container;

    public ServiceCatalog(Container container)
    {
        _container = container;
    }

    public IDepA DepA => _container.GetInstance<IDepA>();
    public IDepB DepB => _container.GetInstance<IDepB>();
    public IDepC DepC => _container.GetInstance<IDepC>();
}

public class ServiceWithCatalog
{
    private readonly ServiceCatalog _catalog;

    public ServiceWithCatalog(ServiceCatalog catalog)
    {
        _catalog = catalog;
    }
}

从我的角度来看

优点:

1. 使用目录的代码很简单
2. 依赖项可以在惰性模式下使用，因此当代码逻辑不使用它们时，它们将不会被创建——但另一方面我知道我们应该以这样的方式设计类，即它们将使用所有依赖项
3. 很容易引导这些类，因为它们有一个预定义的目录

缺点:

1. 对类的依赖不是直接可见的
2. 服务定位器的味道，但我们只在目录定义中使用解析，而不是在业务代码中使用，所以我不确定这是否可以接受，或者依赖注入(inject)警察可能会追捕我们:)

您如何看待这种方法？

Answer 1

您的 ServiceCatalog 类依赖于 Container。这有效地使其成为一个服务定位器，它是一个anti-pattern。 .该类不是“业务代码”这一事实无关紧要。唯一重要的是它不是 Composition Root 的一部分，这使它成为一种反模式。

除了使用反模式外，类公开它的依赖关系，而不是隐藏它们，这也是一个坏主意。这个类的主要思想可能是将常用的依赖项组合在一起，减少一个类具有的构造函数依赖项的数量。然而，这样做的问题是它不会降低消费类的复杂性，而只是掩盖了一个类具有太多依赖项的事实。具有太多依赖项的类可能违反了单一职责原则。

不要使用此服务目录“模式”，而是坚持使用构造函数注入(inject)。当一个类获得过多的构造函数依赖项时，就会出现一种称为构造函数过度注入(inject) 的代码味道，应该采取措施。对此有很多解决方案，例如 Facade Services ，装饰器或领域事件。 Facade 服务隐藏它的依赖关系而不是暴露它们。

所有这些信息以及更多信息都可以在 this book 中阅读，马克·西曼和我本人。