为什么在构造函数中放置一个容器是不好的?例如,您想要在另一个类(C)的构造函数中解析类B,因为您需要使用已解析的依赖项使用类(B)(您开始使用类C时,就像使用已解决的B一样)。
针对最新进展进行编辑:
显然,您正在使用一个依赖于您的类具有默认构造函数的第三方库。让我们假设您没有办法影响您的类的实例化,并且您必须让该框架完成其工作。请注意,这可能是一个很大的假设,请首先调查第三方库是否有可能实现。乍一看,像ASP.NET WebForms和WCF这样的框架并没有给你很多机会,但是在这些情况下有方法可以减轻痛苦。
我的意思只是在构造函数中创建容器,向容器添加相应的依赖项并解析对象,这可以通过简单地创建依赖项对象的实例并使用它来创建相关对象来完成。
我可能漏掉了什么,但是为什么需要在构造函数中注册依赖项?难道您不能在构造函数中解析它,但在其他地方注册它吗?这仍然是服务定位器,但至少您会正确地做错事情。
在任何地方这样做都是一个坏主意,除了一个地方。为什么要将容器注册分散到各个地方呢?如果你真的感觉需要在运行时决定接口的实现,可以使用像工厂一样的东西。为什么在构造函数中这样做是一个坏主意,在其他地方这样做就没问题了?
public class MyClass
{
public MyClass()
: this(Container.Resolve<IDependency>())
{
}
public MyClass(IDependency dep)
{
}
}