Question

注入依赖关系树的依赖关系是模式还是反模式？

例如：

public class ClassExample
{
    private IContainer _container;

    public ClassExample(IContainer container)
    {
        _container = container;
    }
}

public interface IContainer
{
    IDependencyA DependencyA { get; set; }
    IDependencyB DependencyB { get; set; }
    IDependencyC DependencyC { get; set; }
}

public interface IDependencyA
{
}

public interface IDependencyB
{
}

public interface IDependencyC
{
}

上面的示例可以做得更深（一棵树）-例如IDependencyA可以包含更多依赖项IDependencyAA，IDependencyAB等。

当有多个地方需要注入同一组服务时，有人可以使用上述方法来最大程度地减少代码重复。代码最终将看起来像：container.DependencyA.DependencyAA.Method(...)，在许多情况下，它变得更加冗长，而DRY更少。

使用上述方法是一个好主意（模式/反模式）吗？还是什么时候是个好主意，什么时候是个坏主意？

Answer 1

我认为这不是特别好的模式*，但是出于同样的原因，它不会产生很大的变化。

如果在您的示例中，ClassExample依赖于IDependencyA，IDependencyB和IDependencyC，则应将它们全部作为依赖项注入。

更常见的是，IDependencyXX类的具体实现本身具有依赖关系，但不会像您的描述所暗示的那样将它们公开给ClassExample。

*这是一个错误的决定，主要是因为人们迟早会只需要IContainer和IDependencyA（而不是IDependencyB）就开始注射IDependencyC。这是多余的。注入的全部目的是注入所需的依赖项，而不是“以防万一”注入系统中所有可能的依赖项

注入依赖关系，该依赖关系是依赖关系树

1 个答案: