通过接口设计与IoC/DI

oco*_*odo 2 dependency-injection inversion-of-control

很长一段时间以来,我一直在使用基于接口/继承的多态来设计应用程序,以获得松散耦合的代码.据我所知(到目前为止),DI框架/ IoC仅仅提供了使这种"更容易"的工具,但是,额外的抽象级别似乎是多余的,并且需要额外的开销.

我能想到的唯一原因是,如果一个大型团队已经知道特定的DI/IoC框架,那么每个人都可以在同一页面上.

从我的角度来看,DI似乎与界面设计做同样的事情,我希望还有更多的东西,有人可以向我解释为什么使用DI/IoC框架是一个更好的策略吗?

我真的希望我对DI/IoC说错了.

Rub*_*ink 6

首先,你可以阅读这个必要的阅读和编辑从那里的任何缺失点...

如果你期望DI容器a)是非常复杂的野兽或b)一个全新的设计范例,我认为你正在以正常的防御方式做出反应,接近一个过度炒作的概念.

虽然人们可以投入大量精力以各种神秘的方式使用DI容器,并且有很多功能与AOP等重叠,但典型的最佳点是直接自动连接依赖关系而没有任何"全部团队需要理解"任何事情或"开销"(你的意思是概念性还是性能?如果是后者,你是否测量过实际应用中的影响?).

但要理解这一点: - 通过减少摩擦力和增加延展性来实现清洁设计的自由和专注力,因为你扔掉了许多样板代码(如果事情发生变化,还需要重新安装)IOC容器对我来说是一个关键发展生态系统的一部分.虽然他们在new这里和那里只做了几件事,但他们的影响与他们正在做的实际(小)工作不成比例.

至于它们是否与基于正常接口的编程和良好的设计原则不同,我将它们视为更小的东西 - 一种只支持SOLID原则的工具.

  • @slomojo:还有@Mark Seemann(如果您想要好的DI建议,建议在这里阅读他的最高评价的帖子)有一本书即将出版(已经采用电子MEAP形式),我很期待自己-http:// manning。 com / seemann,这可能对您有益。它将涵盖一般情况下依赖管理中涉及的所有微妙模式(以及对特定容器的处理)。希望其他人也能提供一些信息。 (2认同)