引用依赖注入的大多数示例,我们也可以使用工厂模式解决.看起来在使用/设计时,依赖注入和工厂之间的差异是模糊的还是薄的.
一旦有人告诉我你如何使用它会有所作为!
我曾经使用StructureMap一个DI容器来解决问题,后来我重新设计它以使用一个简单的工厂并删除了对StructureMap的引用.
任何人都可以告诉我他们之间的区别是什么,在哪里使用什么,这里最好的做法是什么？
根据Martin Fowler撰写的论文,控制反转是程序控制流程被颠倒的原则:代替程序员控制程序流程,外部源(框架,服务,其他组件)控制它.这就像我们把东西塞进别的东西.他提到了一个关于EJB 2.0的例子:
例如,会话Bean接口定义ejbRemove,ejbPassivate(存储到辅助存储)和ejbActivate(从被动状态恢复).你无法控制何时调用这些方法,只是它们的作用.容器打电话给我们,我们不打电话给它.
这导致框架和库之间的区别:
控制反转是使框架与库不同的关键部分.库本质上是一组可以调用的函数,这些日子通常组织成类.每个调用都会执行一些操作并将控制权返回给客户端.
我认为,DI是IOC的观点,意味着对象的依赖性被颠倒了:相反,它控制着自己的依赖关系,生命周期......还有其他东西为你做.但是,正如你用手告诉我的DI,DI不一定是IOC.我们仍然可以有DI而没有IOC.
然而,在本文中(来自pococapsule,另一个IOC C/C++框架),它表明,由于IOC和DI,IOC容器和DI框架远远优于J2EE,因为J2EE将框架代码混合到组件中因此不能成为普通的旧Java/C++对象(POJO/POCO).
除依赖注入模式之外的控制容器的反转(存档链接)
附加阅读以了解旧的基于组件的开发框架的问题是什么,这导致了上面的第二篇论文:为什么以及什么是控制反转(存档链接)
我的问题:IOC和DI究竟是什么？我很迷惑.基于pococapsule,IOC比仅仅反转对象或程序员和框架之间的控制更重要.
我正在使用unity,我正在创建一个包装它的类,我不知道如何调用它,服务定位器或工厂,都封装了对象的创建,所以....有什么区别？
我正在研究设计模式，有一刻让自己想到了一个想法，即工厂和抽象工厂等大多数创建模式在依赖注入环境的范围内并不是那么有用，在这种环境中我们通常不使用new关键字创建对象，而是“从某种上下文中注入”它们。我也明白我很可能是错的，我需要一个很好的解释来把事情弄清楚。