DI应该在哪里（层）使用？

Question

是否有任何层使用 DI 是不好的做法？在上一个问题中，一位用户提到 DI 应该只用在UI层。

Answer 1

我认为您可能会误解 Daren Dimitrov 提供的答案。除非我弄错了，否则引发这个问题的那句话是：“此外，您不应该在应用程序的业务层中创建与 DI 框架的依赖关系。”

我相信他所说的是所有依赖信息/映射都应该在应用程序的最高级别创建。这并不是说依赖关系不会存在于应用程序的所有层中，只是较低级别不负责设置映射。

如果我的解释是正确的，那么我同意他的观点——在应用程序的表面设置依赖关系映射。相反，如果他说你永远不应该解决较低层的依赖关系，那么我将不得不不同意。

Answer 2

依赖注入 (DI) 应该在任何地方使用。但是，请注意，DI 只是一组模式，而不是框架或库。考虑 DI 的最佳方式是，它是由构造函数注入启用的松散耦合代码。您可以一直编写 DI 友好的代码，而无需引用 DI 容器 或使用服务定位器反模式。

那么，我想到的下一个问题是组件应该在哪里组成？这可能就是原始声明的含义：仅在最外层编写应用程序 - UI 或（Web）服务接口。这就是我所说的组合根。它使其余代码保持模块化和灵活性。

在组合根中，您可以使用Poor Man's DI或适当的DI Container。我强烈建议您使用 DI 容器，但这不是必需的。

为了说明 DI 的含义，这里有一个示例：

public class Foo : IFoo
{
    private readonly IBar bar;

    public Foo(IBar bar)
    {
        if (bar == null)
        {
            throw new ArgumentNullException("bar");
        }

        this.bar = bar;
    }

    public IBaz Baz(ISnafu snafu)
    {
        return this.bar.Snafize(snafu).ToBaz();
    }
}

IBaz 实现可以在与定义 Foo 类的库完全独立的库中实现。此外，堆栈中较高层的消费者不需要了解有关 Foo 和 IBar 的任何信息 - 他们可以只使用 IFoo：

public class MyClass : ISomeInterface
{
    private readonly IFoo foo;

    public MyClass(IFoo foo)
    {
        if (foo == null)
        {
            throw new ArgumentNullException("foo");
        }

        this.foo = foo;
    }

    // ...
}

这提供了松散耦合，这是 DI 的动机。根据需要重复多次。

Answer 3

DI 应该用在一个组件依赖于另一个组件的任何情况下，无论是 UI --> 还是 UI。商业，商业——>数据访问或其他什么。我不认为它应该只用于 UI，只是 DI 使测试 UI 变得更容易，因此似乎有更多直接的好处。

Answer 4

我不同意这种说法。您引用的上一个问题要么不正确，要么您误解了它。

DI当然不仅仅存在于UI层。我只会同意这一点，前提是控制器是视图层的一部分。

只要可以正确提供依赖项，就可以使用 DI。

无论您选择使用工厂还是 DI 解决方案，都是您的选择。