我感觉不存在控制倒置这样的事情,或者说正确的术语是依赖注入.我错了这个假设吗？
我一直试图为自己定义IoC.在这样做的过程中,我学到了很多关于IoC容器和依赖注入的知识.
刚才,我从Martin Fowler的网站上看到了这个:
结果我认为我们需要一个更具体的名称来模式.控制反转过于笼统,因此人们会发现它令人困惑.结果与各种IoC倡导者进行了大量讨论,我们选择了Dependency Injection这个名称.
在现代IoC世界中,依赖注入只是实现IoC的一种方式吗？
我已经阅读了许多解释IoC和DI之间差异的线程,虽然许多解释相互矛盾,但我认为它们仍然帮助我理解了它们之间的区别.
所以在这里我想问一下我的理解是否正确,并且发布了有助于我的摘录(虽然其中一些相互矛盾).
我知道在这个问题上已经有很多线程,但我希望这个线程不会被关闭,因为我不认为提到的线程中的任何OP也显示所有相关的帖子(来自各种线程)他们终于明白了.
无论如何,这是我理解的方式(如果可能,请单独解答/回答每个问题):
a)当我们在框架层面应用DIP原则时,我们使用术语IoC？在框架层面实施DIP的机制之一是DI？
b)当我们在较低级别/非框架级别实施DIP(使用DI)时,术语IoC不适用,在这种情况下,我们简称为DI？
c)DI通过将实际创建和选择依赖关系的控制权传递给第三方来帮助我们实现DIP,第三方对所涉及的其他2个中立方是中立的？
d)当在框架级(IoC)应用DIP(使用DI)时,三种类型的控制被反转:
界面的控制.现在,高级模块正在控制低级模块需要遵循的接口,而不是相反
控制流量.- >现在框架代码(而不是用户/业务代码)控制程序的流程(换句话说 - 它们(即框架)调用你(即业务代码) )
依赖创建的控制.这种反转将实际创建和选择依赖关系的控制权传递给第三方,该第三方对所涉及的其他2个中立方是中立的.
e)当在非框架级别应用DIP(使用DI)时,两种类型的控制被反转:
界面的控制.现在,高级模块正在控制低级模块需要遵循的接口,而不是相反
依赖创建的控制.这种反转将实际创建和选择依赖关系的控制权传递给第三方,该第三方对所涉及的其他2个中立方是中立的.
？
以下摘录有助于:
控制反转是通用术语.依赖注入是一种特定类型的IoC
...
控制反转是指框架/基础架构调用应用程序代码,而不是相反
...
可以在不做IoC的情况下进行DI.如果你将一个ConcesoleStringWriter注入到HelloWorld中,我并不认为这是IoC,因为没有"框架"或"基础架构".
如果您接受Fowler的定义,那么控制反转是一个比DI更广泛的术语,涵盖了插入框架的所有框架使用,但框架仍处于控制之中.依赖注入是IoC的一个专门化,它专门用于管理依赖关系.