inversion-of-control - 是否有任何理由不将我的 IoC 用作通用设置存储库？

Question

假设 应用程序设置 class 是适用于我的应用程序的通用设置存储库，例如 TimeoutPeriod、DefaultUnitOfMeasure、HistoryWindowSize 等...假设 MyClass 使用其中一个设置 - DefaultUnitOfMeasure。

我对正确使用控制容器反转的阅读——如果我在这方面错了请纠正我——是你在它的构造函数中定义了一个类的依赖关系:

public class MyClass {
  public MyClass(IDataSource ds, UnitOfMeasure default_uom) {...}
} 

然后用类似的方法调用实例化你的类

var mc = IoC.Container.Resolve<MyClass>();

在哪里 数据源 已经分配了一个具体的实现，并且 default_uom 已经连接到从 实例化。 ApplicationSettings.DefaultUnitOfMeasure 属性(property)。然而，我不得不怀疑，如果所有这些箍真的有必要跳过。我有什么麻烦我应该怎么做

public class MyClass {
  public MyClass(IDataSource ds) {
    UnitOfMeasure duom = IoC.Container.Resolve<UnitOfMeasure>("default_uom");
  }
} 

是的，我的许多类(class)最终都依赖于 。 IoC.Container 但这是我的大多数类(class)无论如何都会有的依赖项。只要类是耦合的，我似乎应该充分利用它。请敏捷大师，告诉我我错在哪里。

Answer 1

IoC.Container.Resolve("default_uom");

我认为这是一个经典的反模式，您将 IoC 容器用作服务定位器 - 导致的关键问题是:

如果您的容器配置错误，您的应用程序将不再快速失败(您只会在它第一次尝试在代码中解析该特定服务时才知道它，除了一组特定的逻辑/情况外，这可能不会发生)。

更难测试 - 当然不是不可能，但是您要么必须为测试创建一个真实的(和半配置的)windsor 容器实例，要么使用 IWindsorContainer 的模拟注入(inject)单例 - 这给测试增加了很多摩擦，与仅能够通过构造函数/属性将模拟/ stub 服务直接传递到您的测试类相比。

更难维护这种应用程序(配置不是集中在一个位置)

违反了许多其他软件开发原则(DRY、SOC 等)

您原始陈述的相关部分暗示您的大多数类将依赖于您的 IoC 单例 - 如果它们通过构造函数/依赖项注入(inject)所有服务，那么与 IoC 有一些紧密耦合应该是异常(exception)规则 - 通常我唯一依赖容器的时候是当我做一些棘手的事情时，即试图避免循环依赖问题，或者出于某种原因希望在运行时创建组件，即使这样我也可以通常避免依赖于通用 IServiceProvider 接口(interface)之外的任何东西，如果我需要在原始项目之外的环境中重用组件，则允许我交换自制 IoC 或服务定位器实现。