使用选定引号反转控制与依赖注入 - 我的理解是否正确？

Question

我已经阅读了许多解释IoC和DI之间差异的线程,虽然许多解释相互矛盾,但我认为它们仍然帮助我理解了它们之间的区别.

所以在这里我想问一下我的理解是否正确,并且发布了有助于我的摘录(虽然其中一些相互矛盾).

我知道在这个问题上已经有很多线程,但我希望这个线程不会被关闭,因为我不认为提到的线程中的任何OP也显示所有相关的帖子(来自各种线程)他们终于明白了.

无论如何,这是我理解的方式(如果可能,请单独解答/回答每个问题):

a)当我们在框架层面应用DIP原则时,我们使用术语IoC？在框架层面实施DIP的机制之一是DI？

b)当我们在较低级别/非框架级别实施DIP(使用DI)时,术语IoC不适用,在这种情况下,我们简称为DI？

c)DI通过将实际创建和选择依赖关系的控制权传递给第三方来帮助我们实现DIP,第三方对所涉及的其他2个中立方是中立的？

d)当在框架级(IoC)应用DIP(使用DI)时,三种类型的控制被反转:

1. 界面的控制.现在,高级模块正在控制低级模块需要遵循的接口,而不是相反

2. 控制流量.- >现在框架代码(而不是用户/业务代码)控制程序的流程(换句话说 - 它们(即框架)调用你(即业务代码) )

3. 依赖创建的控制.这种反转将实际创建和选择依赖关系的控制权传递给第三方,该第三方对所涉及的其他2个中立方是中立的.

e)当在非框架级别应用DIP(使用DI)时,两种类型的控制被反转:

1. 界面的控制.现在,高级模块正在控制低级模块需要遵循的接口,而不是相反

2. 依赖创建的控制.这种反转将实际创建和选择依赖关系的控制权传递给第三方,该第三方对所涉及的其他2个中立方是中立的.

？

以下摘录有助于:

为什么这么多术语说同样的话呢？IoC和DIP

控制反转是通用术语.依赖注入是一种特定类型的IoC

...

控制反转是指框架/基础架构调用应用程序代码,而不是相反

...

可以在不做IoC的情况下进行DI.如果你将一个ConcesoleStringWriter注入到HelloWorld中,我并不认为这是IoC,因为没有"框架"或"基础架构".

控制反转<依赖注入

如果您接受Fowler的定义,那么控制反转是一个比DI更广泛的术语,涵盖了插入框架的所有框架使用,但框架仍处于控制之中.依赖注入是IoC的一个专门化,它专门用于管理依赖关系.

IoC和DI之间的区别究竟在哪里

IoC是改变合同执行的能力.DI是提供实施的能力.

...

在传统应用程序中,开发人员会编写业务代码和框架代码.然后,业务代码将调用框架代码来完成任务.在IoC模型下,您"反转"该模型并创建一个接受业务模块并调用它们来完成任务的框架

依赖注入是一种通过允许外部调用者将依赖对象注入到类/方法中来从实现中删除内部依赖性的技术(很难称之为模式).IoC框架使用依赖注入将用户模块和其他依赖代码提供给"将它们粘合在一起"的框架例程.依赖注入被IoC框架大量使用,因为这是允许它们"呼叫你"的机制.

DIP vs. DI与IoC

DIP是引导我们走向DI的原则.基本上,松散耦合是目标,并且至少有两种方法可以实现它.•依赖注入•服务定位器

有没有人对依赖注入有一个很好的比喻？

控制反转(其中依赖注入是一种实现)的本质是将对象的使用与其管理分离.

ioc和依赖注入之间的区别

术语依赖注入(DI)和控制反转(IoC)通常可互换使用来描述相同的设计模式(虽然并非所有人都同意这一点,但有些人倾向于以稍微不同的方式应用它们).该模式最初称为IoC,但Martin Fowler建议转向DI,因为所有框架都以某种方式反转控制,他希望更具体地说明控制的哪个方面被颠倒了.

控制反转与依赖注入

控制反转(IoC)意味着对象不会创建他们依赖的其他对象来完成工作.相反,他们从外部源获取所需的对象(例如,xml配置文件).依赖注入(DI)意味着这是在没有对象干预的情况下完成的,通常由传递构造函数参数和设置属性的框架组件完成.

谢谢

Answer 1

那么这是我的观点:

DIP意味着您针对抽象进行编程.您可以将依赖项的类型从实现转换为抽象.

IOC意味着其他人负责获取给定抽象的实现.通常,消费者会使用new关键字来获得依赖关系.使用IoC,您可以反转控件,这样消费者就不再负责创建实例了.

依赖注入和服务位置是控制反转的一部分.

另见:https://stackoverflow.com/a/10053413/175399