dependency-injection - 依赖注入(inject)框架会导致糟糕/懒惰的设计吗？

Question

我对 DI 概念还很陌生，但我在设计中一直在某种程度上使用它——主要是通过将接口(interface)“注入(inject)”到构造函数中并让工厂创建我的具体类。好的，它不是基于配置的——但它从来不需要。

我开始研究 DI 框架，例如 Spring.NET 和 CaSTLe Windsor，偶然发现了这个 blog通过艾扬德。

我从中得到的是

A) DI 框架很棒，但是
B)这意味着我们不必担心我们的系统是如何根据依赖关系设计的。

对我来说，我习惯于认真思考如何松散耦合我的系统，但同时对依赖项有某种控制。

我有点害怕失去这种控制，而这只是一场混战。 ClassA 需要 ClassB = 没问题，问就收!嗯。

或者这只是重点，这就是 future ，我应该接受它？

想法？

Answer 1

一个基本的 OO 原则是您希望您的代码依赖于接口(interface)而不是实现，DI 就是我们这样做的方式。从历史上看，它是如何演变的:

人们最初通过"new"创建他们所依赖的类:

IMyClass myClass = new MyClass();

然后我们想删除实例化，所以有静态方法来创建它们:

IMyClass myClass = MyClass.Create();

然后我们不再依赖类的生命周期，但仍然依赖它进行实例化，所以我们使用了工厂:

IMyClass myClass = MyClassFactory.Create();

这将直接依赖从消费代码转移到工厂，但我们仍然间接依赖 MyClass，所以我们使用了这样的服务定位器模式:

IMyClass myClass = (IMyClass)Context.Find("MyClass");

这样，我们只依赖于代码中的接口(interface)和类的名称。但它可以做得更好，为什么不简单地依赖我们代码中的一个接口(interface)呢？我们可以使用依赖注入(inject)。如果您使用属性注入(inject)，您只需在代码中为您想要的接口(interface)放置一个属性 setter 。然后，您配置代码之外的实际依赖项，容器管理该类和您的类的生命周期。