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

时间:2012-07-03 18:09:52

标签: dependency-injection inversion-of-control

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

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

我知道在这个问题上有很多线程,但我希望这个帖子不会被关闭,因为我不认为所提到的线程中的任何OP也显示了所有相关帖子(来自不同的主题)帮助他们最终理解它。

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

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

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

c) DI 通过将实际创建和选择依赖项的控制权传递给第三方来帮助我们实现 DIP ,第三方对另一方保持中立2涉及?

d)在框架级(IoC)应用 DIP (使用 DI )时,三种类型的控件会被反转:< / p>

  1. 界面的控制。现在,高级模块正在控制较低级别模块需要遵守的界面而不是相反的方式

  2. 对流程的控制。 - &gt;现在框架代码(而不是用户/业务代码)控制程序的流程(换句话说 - 他们(即框架)调用你(即业务代码) )

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

  4. e)当非框架级应用 DIP (使用 DI )时,两种类型的控件会被反转:

    1. 界面的控制。现在,高级模块正在控制较低级别模块需要遵守的界面而不是相反的方式

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

    3. 以下是有帮助的摘录:

      Why so many terms to say the same thing? IoC and DIP

        

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

           

      ...

           

      控制反转是框架/基础设施调用的时间   应用程序代码,而不是相反的方式

           

      ...

           

      可以在不进行IoC的情况下进行DI。如果将aConsoleStringWriter注入到   HelloWorld我并不认为这是IoC,因为没有   &#34;框架&#34;或者&#34;基础设施&#34;。

      Inversion of Control < Dependency Injection

        

      如果你接受福勒的定义,那么控制倒置就是一个很大的问题   比DI更广泛的术语,涵盖了您插入的所有框架使用   进入框架,但框架仍在控制之中。依赖   注入是IoC的专门化,专门应用于IoC   管理依赖关系。

      Where exactly is the difference between IoC and DI

        

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

           

      ...

           

      在传统应用程序中,开发人员会编写业务代码和   框架代码。然后,业务代码将调用框架代码   完成任务。在IoC模型下,你&#34;反转&#34;那个模型和   创建一个接受业务模块并调用它们的框架   完成任务

           

      依赖注入是一种技术(很难称之为模式,   真的)从实现中删除内部依赖项   允许依赖对象通过a注入类/方法   外部来电者。 IoC框架使用依赖注入来提供   用户模块和其他依赖代码到框架例程&#34;粘合   这一切都在一起。&#34; IoC大量使用依赖注入   框架,因为这是允许他们“呼叫”的机制   你&#34;

      DIP vs. DI vs. IoC

        

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

      Does anyone have a good analogy for dependency injection?

        

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

      Difference between ioc and dependency injection

        

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

      Inversion of Control vs Dependency Injection

        

      控制反转(IoC)意味着对象不会创建其他对象   他们依赖的对象来做他们的工作。相反,他们得到了   他们需要来自外部源的对象(例如,xml   配置文件)。依赖注入(DI)意味着这样做   没有对象干预,通常由框架组件   传递构造函数参数和设置属性。

      谢谢

2 个答案:

答案 0 :(得分:17)

这是我的观点:

DI Overview

DIP 表示您针对抽象进行编程。您可以将依赖项的类型从实现转换为抽象。

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

依赖关系注入服务位置控制反转的一部分。 DIvsSL

另请参阅:https://stackoverflow.com/a/10053413/175399

答案 1 :(得分:0)

我在[博客]写了差异:http://dotnet-stuff.com/tutorials/dependency-injection/dependency-inversion-principle-dependency-injection-and-inversion-of-control-dip-ioc-and-di“点击此处了解更新”我们如何组织控制反转,依赖倒置原理&amp;依赖注入。简而言之,我们可以说 -

最重要的是依赖倒置原则,这是一种设计软件的方法。它没有说如何制作独立的模块。控制反转(IoC)提供了应用DPI原理的方法。但是IoC仍然没有为我们提供具体的实现。它提供了一些方法,以便我们可以反转控件。如果我们想要使用Binding inversion或依赖项创建来反转控制,那么我们可以通过实现依赖注入(DI)来实现它。