为什么 IOC 容器被认为是减少耦合的一种方式？

Question

我正在考虑在我的项目中使用 DI 和 Unity。我有一个问题：它将如何减少耦合？从我的角度来看，它正在增加耦合，因为：

1. 我需要创建 UnityContainer 并在那里注册所有类型。这意味着我需要引用创建此容器的程序集中的所有程序集。

   IUnityContainer UnityContainer;
   //....
   IUnityContainer UnityContainer= new UnityContainer();
   UnityContainer.RegisterType();
   

2. 我需要使用 Resolve 创建服务实例，但这意味着我需要使用容器引用程序集。

   var service = SomeClassWithContainer.UnityContainer.Resolve();
   

我是否误解了某些东西，或者实际上它正在增加耦合？

Answer 1

我认为您误解了应该如何解决您的依赖关系。

1.) 仅在引导代码中需要引用 Unity，引导代码位于应用程序的单个中心位置。

2.) 一旦引导完成，所有依赖项（理想情况下）都将使用构造函数注入来解析，如果包含类是通过 Unity 解析的，则由 Unity 自动完成 - 它会向下滴入对象图。您使用的示例实际上只是“服务定位器”模式，而不是 DI。

这确实减少了耦合，因为您不是直接创建您的类所依赖的具体类，而是将依赖项（同样理想的是一些抽象，如接口）“注入”到您的类中，这允许您用其他类替换这些依赖项，即在单元测试场景中。

Answer 2

您的问题包含服务定位器反模式的示例：

public class UsesMyService
{
    private readonly IMyService _service;

    public UsesMyService()
    {
        _service = SomeClassWithContainer.UnityContainer.Resolve<IMyService>();
    }
}

由于信息流动的方向，这与依赖注入模式根本不同：在上面的示例中，您伸出援手并询问服务，而在下面的示例中，您将获得服务：

public class UsesMyService
{
    private readonly IMyService _service;

    public UsesMyService(IMyService service)
    {
        _service = service;
    }
}

这种模式称为构造函数注入，它将 UsesMyService 类与周围基础设施的详细信息分离。现在，任何拥有 IMyService 实现的人都可以创建 UsesMyService 实例，而无需知道如何配置中央静态位置。

他们怎么知道要配置什么？他们要么需要源代码，要么需要一些文档来告诉他们该类依赖于 IMyService。构造函数参数清楚地向消费者表达了该要求，无需任何外部引用。

如果您在整个库中遵循这种模式，则您将承担将对象一直组装到最外层（称为组合根）的责任。这个位置（通常是顶级应用程序类）是唯一引用您正在使用的所有库的位置。 这就是容器所在的位置，整个解决方案中的其他类都不需要引用它。