我听到很多人说使用 IoC.Resolve() 是一种不好的做法，但我从来没有听到一个很好的理由（如果这完全是为了测试而不是你可以模拟容器，那么你就是完成）。
现在使用 Resolve 代替 Constructor Injection 的优点是你不需要创建 在构造函数中具有 5 个参数的类，以及每当您要创建 那个类你不需要为它提供任何东西
【问题讨论】：
标签： .net inversion-of-control ioc-container
IoC.Resolve<> 是Service Locator 模式的一个示例。该模式施加了一些构造函数注入没有的限制：
在我看来，这些限制将服务定位器模式置于大泥球和依赖注入之间的中间地带：如果你必须使用它，它很有用，但目前还不是最佳选择。
【讨论】：
IoC.Resolve<> 是服务定位器 anti 模式的一个示例。
IEmailService 具有两种实现：一种发送实时电子邮件，另一种仅发送到本地服务器。如果Foo 类通过IoC.Resolve<> 请求IEmailService，它只能选择其中一个——在决定要解决哪个IEmailService 配置时，不会考虑使用它的上下文。 Foo 的所有实例都将获得与 IEmailService 完全相同的配置。
IEmailService 下注册（表明它是该合约的默认实现）。本地配置将在IEmailService ("Local") 下注册，表明它必须通过名称引用。使用构造函数注入，对象不知道它得到的是哪个版本；使用服务定位器，它必须决定它获得哪个版本。
如果你创建的类有 5 个依赖项，你会遇到 IoC.Resolve 以外的问题。
拉取依赖（而不是通过构造函数推送它们）完全忽略了使用 IoC 框架的意义。您想反转依赖关系。不是让你的类依赖于 IoC 框架，而是反过来。
如果您在某些情况下不需要所有依赖项，那么也许您应该拆分您的类，或者通过使它们成为属性依赖项来使某些依赖项成为可选。
您的类取决于容器。除非您为他们提供一个，否则它们将无法工作。是真的还是假的都无所谓。它们本质上是通过静态依赖绑定到容器的。这会给你带来额外的工作来对你的类做任何事情。任何时候你想使用你的类，你都需要用它们拖动容器。没有任何好处！服务定位器只是一个全局包，这可能违反了面向对象编程的所有原则。
【讨论】：
Ioc.Resolve 本质上是服务定位器模式。它有它的位置，但并不理想。从架构的角度来看，构造函数注入是首选，因为依赖关系更加明确，而 SL 将依赖关系隐藏在类中。这会降低可测试性，并使过程变得比需要的更复杂。
如果可以的话，我建议您阅读 my series，了解减少代码耦合的技术，其中包括 SL、DI 和 IoC。
【讨论】：
一个优点是使用构造函数注入，所有类依赖项都是预先可见的。
使用.Resolve，您必须阅读代码才能找出依赖关系。
【讨论】：
我必须指出，跳过构造函数注入并使用静态注入并不一定是邪恶的。这有很多很好的应用，最具体的例子是在工厂模式实现中使用它。
public static class ValidationFactory
{
public static Result Validate<T>(T obj)
{
try
{
var validator = ObjectFactory.GetInstance<IValidator<T>>();
return validator.Validate(obj);
}
catch (Exception ex)
{
var result = ex.ToResult();
...
return result;
}
}
}
我将它与 StructureMap 一起使用来处理我的验证层。
编辑：我直接使用容器的另一个例子是让你的一些域对象成为单例而不使它们成为静态类并引入静态类所做的所有奇怪。
在我的某些观点中，我连接了一些这样的实体。通常我会给我们一个带有 Description 属性的 Enum 来给我 3 个值选择，但在这种情况下，第 3 个也需要是一个字符串而不是一个 int，所以我创建了一个具有这 3 个属性的接口并继承了所有域对象它。然后我让我的容器扫描我的程序集并自动注册所有它们然后将它们拉出我刚刚拥有的
SomeObject ISomeView.GetMyObject
{
get { return new SomeObject { EmpoweredEnumType =
ObjectFactory.GetNamedInstance<IEmpEnum>("TheObjectName");
}
}
【讨论】：
由于这个问题值得商榷，我不会说“使用这个或那个”
看起来使用服务定位器不是一件坏事，如果你可以依赖它（我们通常在某些 DI 框架上做任何事情）。借助 DI，我们可以轻松地更改框架，借助 Service Locator，我们可以创建与框架的 SL 部分的耦合。
关于 Bryan Watts 在您稍后阅读时的回答 Service Locator vs Dependency Injection
...使用 [constructor] 注入没有显式请求，服务出现在应用程序类中 - 因此 控制反转。
控制反转是框架的一个常见特性，但它是有代价的。当您尝试调试时，它往往难以理解并导致问题。 所以总的来说，除非我需要它，否则我宁愿避免它。这并不是说这是一件坏事，只是我认为它需要证明自己比更直接的选择更合理。
然后，如果您稍后阅读，这是实际使用构造函数注入（控制反转）的另一个理由。
我的观点是，在小型项目中使用 SL 是可以的，因为主要不是在我们自定义开发的类之间创建耦合。
使用 StructureMap 示例，这应该是可以接受的：
public class Demo
{
private ISomething something = ObjectFactory.GetInstance<ISomething>();
private IFoo foo = ObjectFactory.GetInstance<IFoo>();
}
是的，代码取决于 SM Frx，但是您多久更改一次 DI Frx？
对于单元测试，可以设置一个模拟
public class SomeTestClass
{
public SomeTest()
{
ObjectFactory.Inject<ISomething>(SomeMockGoesHere);
ObjectFactory.Inject<IFoo>(SomeMockGoesHere);
Demo demo = new Demo() //will use mocks now
}
}
使用 Resolve 代替 Constructor Injection 的优点是您不需要在构造函数中创建具有 5 个参数的类
但您最终可能会为单元测试制作更多“管道”。
【讨论】：
我会说这是要注入的大量参数。
争取一个参数，最多可能2个，这在几乎所有场景中都是可能的，当然应该是一个接口。不仅如此，我还闻到了老鼠的味道（设计缺陷）。
【讨论】：
您不需要在构造函数中创建具有 5 个参数的类，并且无论何时要创建该类的实例，您都不需要为它提供任何东西
几点：
即使您没有通过类的 API（在本例中为构造函数）表明依赖关系也会存在。然而，像这样试图隐藏它们的依赖关系的类会更难理解和测试。
【讨论】：