相关疑难解决方法(0)

在一些情况下,我最常使用"混蛋注射".当我有一个"适当的"依赖注入构造函数时:

public class ThingMaker {
    ...
    public ThingMaker(IThingSource source){
        _source = source;
    }

但是,对于我打算作为公共API(其他开发团队将使用的类)的类,我永远找不到比编写具有最可能需要的依赖项的默认"bastard"构造函数更好的选择:

    public ThingMaker() : this(new DefaultThingSource()) {} 
    ...
}

这里明显的缺点是,这会对DefaultThingSource产生静态依赖; 理想情况下,没有这种依赖性,消费者总是会注入他们想要的任何IThingSource.但是,这太难用了; 消费者希望新建一个ThingMaker并开始制作物品,然后几个月后,在需要时注入其他东西.在我看来,这只留下了几个选项:

1. 省略这个混蛋构造函数; 迫使ThingMaker的消费者理解IThingSource,了解ThingMaker如何与IThingSource交互,查找或编写具体类,然后在构造函数调用中注入实例.
2. 省略bastard构造函数并提供单独的工厂,容器或其他引导类/方法; 以某种方式让消费者明白他们不需要编写自己的IThingSource; 迫使ThingMaker的消费者找到并理解工厂或引导程序并使用它.
3. 保持bastard构造函数,使消费者能够"新建"一个对象并使用它运行,并处理DefaultThingSource上的可选静态依赖.

男孩,#3肯定看起来很有吸引力.还有另一种更好的选择吗？#1或#2似乎不值得.

从".Net中的依赖注入"一书中我知道应该在应用程序的组合根处创建对象图,这对我来说在使用IoC容器时很有意义.

在我尝试使用DI时所见到的所有应用程序中,总有两个构造函数:一个具有依赖关系作为参数的构造函数和一个没有参数的"默认"构造函数,而这些构造函数又调用另一个"newing"所有的依赖关系,但在上述书中,这被称为"混蛋注射反模式",这就是我曾经知道的"穷人的注射".

现在考虑所有这些,我会说"穷人注射"只是不使用IoC容器而是在所述组合根上手动编码所有对象图.

所以我的问题是:

1. 我是否正确理解了这些概念,还是完全偏离了轨道？
2. 如果您仍然需要在IoC容器中注册所有依赖项,而不是在完全相同的组合根中手动编码,那么使用IoC容器的真正好处是什么？
3. 如果我误解了"穷人的注射"究竟是什么,有人可以澄清一下吗？

谢谢