design-patterns - 我们是否有效地使用了 IoC？

Question

所以我公司使用Castle Windsor IoC container ，但以一种感觉“关闭”的方式:

所有数据类型都注册在代码中，而不是配置文件中。

所有数据类型都经过硬编码以使用一种接口(interface)实现。事实上，对于几乎所有给定的接口(interface)，只有一种实现方式。

所有注册的数据类型都有一个默认构造函数，因此 Windsor 不会为任何注册的类型实例化对象图。

设计系统的人坚持 IoC 容器让系统变得更好。我们有 1200 多个公共(public)类，所以它是一个很大的系统，你希望找到像 Windsor 这样的框架。但我仍然持怀疑态度。

我的公司是否有效地使用了 IoC？使用 Windsor 新建对象是否比使用 new 新建对象有优势？关键词？

Answer 1

简短的回答:没有 ，您的公司没有有效地使用 DI。

稍长的答案:主要问题是所有类都有 默认构造函数 .在这种情况下，您如何解决依赖关系？

您的构造函数具有这样的硬编码依赖项:

public Foo()
{
    IBar bar = new Bar();
}

在这种情况下，您不能在不重新编译该应用程序的情况下更改依赖项。

更糟糕的是，他们可能会使用 Static Service Locator anti-pattern :

public Foo()
{
    IBar bar = Container.Resolve<IBar>();
}

DI 容器应该解析应用程序的 Composition Root 中的整个依赖关系图。并让开。

一般情况下最好使用 约定优于配置通过在代码中使用启发式方法来配置容器。 XML 配置应该保留用于需要能够重新配置依赖关系的少数情况 无需重新编译 ，这应该只是一个小子集。简而言之，我认为在代码中配置容器没有任何固有问题。事实上，这是首选方法。

每个接口(interface)只有一个实现也不是问题。这是一个开始，如果应用程序真正松耦合，它是 不断打开机会之窗 .迟早您很可能会引入替代实现，但如果接口(interface)已经到位并且整个代码库都遵循 Liskov Substitution Principle，则最好这样做。 .