时间戳

首页 > 解决方案 > 注入一个依赖关系树

c# - 注入一个依赖关系树

问题描述

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

例如：

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。

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

标签： c#design-patternsdependency-injectionanti-patterns

解决方案

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

如果，使用您的示例，ClassExample取决于IDependencyA, IDependencyB&IDependencyC那么它们都应该作为依赖项注入。

更常见的是，您的IDependencyXX类的具体实现本身具有依赖关系，但不要ClassExample像您的描述所暗示的那样将它们暴露出来。

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

推荐阅读