.net - IoC.Resolve 与构造函数注入(inject)

Question

我听到很多人说使用 IoC.Resolve() 是一种不好的做法，但我从未听说过一个好的理由(如果这都是关于测试的，那么你可以只是模拟容器，而且你完成)。

现在使用Resolve代替构造函数注入(inject)的优点是你不需要创建构造函数中有 5 个参数的类，并且每当您要创建 的实例时那个类你不需要提供任何东西

Answer 1

IoC.Resolve<>是 Service Locator 的一个示例图案。该模式施加了一些构造函数注入(inject)没有的限制:

• 由于静态调用，对象不能拥有比应用程序域更细粒度的上下文
• 对象决定要解析的依赖项的版本。某个类的所有实例都将获得相同的依赖配置。
• 将代码耦合到容器的诱惑很大，例如，而不是创建一个意图揭示工厂。
• 单元测试需要容器配置，否则可以在其中创建和使用类。 (由于上面的第二个问题，当您想要测试同一类的多个配置时，这尤其麻烦。)
• 应用程序的结构无法从其公共(public) API 推断出来。 (构造函数参数是一件好事。它们不是您认为需要解决的问题。)

在我看来，这些限制使服务定位器模式处于大泥球和依赖注入(inject)之间的中间地带:如果您必须使用它，它很有用，但到目前为止不是最佳选择。