依赖注入框架会导致糟糕/懒惰的设计吗？

我对DI概念很新,但我在设计中已经在某种程度上使用它 - 主要是通过'注入'接口到构造函数并让工厂创建我的具体类.好的,它不是基于配置的 - 但它永远不需要.

我开始研究诸如Spring.NET和Castle Windsor之类的DI框架,并偶然发现了Ayende的博客.

我从中得到的是

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

对我来说,我已经习惯于如何松散地耦合我的系统,但同时对依赖关系进行某种控制.

我有点害怕失去这种控制,它只是一个免费的.ClassA需要ClassB =没问题,只要问,你就收到了!嗯.

或者这就是重点,这就是未来,我应该选择它吗？

思考？

一个基本的OO原则是您希望您的代码依赖于接口而不是实现,DI就是我们如何做到的.从历史上看,这是它的演变过程:

人们最初通过"新"他们创造了他们所依赖的课程:


IMyClass myClass = new MyClass();

然后我们想要删除实例化,因此有静态方法来创建它们:


IMyClass myClass = MyClass.Create();

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


IMyClass myClass = MyClassFactory.Create();

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

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

这样我们只依赖于代码中的接口和类的名称.但它可以做得更好,为什么不简单地依赖于我们代码中的接口？我们可以依赖注入.如果使用属性注入,则只需在代码中为所需的接口添加属性setter.然后,配置实际依赖项在代码之外的内容,容器管理该类和类的生命周期.

我不会说您不必考虑依赖关系,但使用IoC框架允许您更改满足依赖关系的类型,几乎没有麻烦,因为所有布线都在中心位置完成.

你仍然需要考虑你需要什么样的接口,并且正确地使用它们并不总是一件小事.

我没有看到一个松散耦合的系统如何被认为是懒惰的设计.如果您经历了了解IoC框架的所有麻烦,那么您肯定不会采用这种捷径.