Question

DI / IOC：有很多框架，这些示例很快就会对该框架特有的细节产生影响。我发现如果我能在框架之外学习它的原理（森林掩盖了树木），我经常会学到一种最好的新技术。

我的问题：DI / IOC的简单原则是什么？我正在寻找一种（框架无关的）构建方法，它概述了每个简单原则所获得的内容，选项是什么，成本是什么。请不要只是粘贴链接，除非他们真正解决我的问题。我一直迷失在那些森林里;}

第二个问题：一旦我理解了核心原则，是否值得建立我自己的简单框架？ IE，相对于所花费的努力，获得的洞察力是否有价值？

提前致谢！罗伯特

Answer 1

我对它的快速和肮脏的看法

依赖注入和控制反转不相同。控制反转使用 DI。
IoC是一种在运行时将应用程序捕捉到一起而不是编译时的方法。
代替在代码中“新建”类型，它在运行时由IoC容器注入。
IoC容器知道要在你的类中注入什么，因为 a）它查看该类的构造函数 - 所有参数都是接口。 b）查看其配置文件，并查看实现您选择的每个接口的类，以表示应用程序中的该接口。

这是一个非常基本的例子

假设您有一个用于发送电子邮件的界面IEmailer：

public interface IEmailer
{
    void SendEmail();
}

您至少有一个此接口的实现：

public class IainsEmailer : IEmailer
{
    public void SendEmail()
    {
        // Send email
    }
}

您在IoC容器的配置文件中定义（以某种方式）：

IainsEmailer is my choice for IEmailer

然后在您的代码中，您可以拥有以下内容，IoC容器会将IainsEmailer注入任何需要IEmailer的构造函数。

public class MyClass
{
    private IEmailer _emailer;

    public MyClass(IEmailer emailer)
    {
        _emailer = emailer
    }

    // You can now use emailer as if you have created it
    _emailer.SendEmail();
}

我可以继续。而且。但这简直就是IoC的全部概念。

Answer 2

这是一个有点过时但很好的概述Inversion of Control

对我而言，驱动Ioc的基本原则是组件，模块化，松耦合，内聚的概念。这意味着您可以将软件设计为具有明确依赖关系的内聚模块化单元，或者链接到其他单元。这是任何领域的工程学基本原理，而不仅仅是编程。一旦您具有模块化，要创建一个功能系统，您需要一种方法来链接这些组件，以便它们形成一个功能整体。 IoC / DI框架是抽象这种链接概念的组件，允许您编写声明组件之间链接的代码，然后能够执行这些链接。 “反转”部分来自这样的事实：组件本身不再链接到它们的依赖关系，而是通过链接组件在外部执行链接。反过来，这称为依赖注入。典型的IoC / DI框架允许您编写指定另一个组件所依赖的接口的特定实现的代码，然后允许您实例化该组件，并且在创建时，IoC容器将提供所需的实现。然后，它抽象出对象创建的概念。

Answer 3

您的问题需要完整的维基百科文章。我假设您已经阅读了实际的文章，所以这里是我对您的问题的简短描述：依赖注入就是实例化。

主要思想是类不应该负责实例化它们的依赖项。 DI框架接管实例化，因为它可以通过（通常）代码外部的配置机制灵活地进行实例化。

这使您可以编写以下类：

与其依赖关系分离。
更好地关注他们的实际责任（而不是他们的依赖）
可以通过配置进行更改，无需重新编译。
更容易测试。
可以说是设计得更好。

回答你的第二个问题：如果你正在尝试学习关于DI，那么自己编写一个框架显然是过度的。我建议你选择一个流行的开源框架并编写消耗它的代码 - 大多数都有专门用于此目的的教程。

将它提升到一个新的水平，您可以获取您正在使用的框架的源代码并开始深入研究它。良好的框架编写得非常好，而且相对容易阅读。

PS - 如果你在.net，请不要以MEF开头。从Windsor，Unity或Spring.Net开始。 MEF比DI框架更多也更少，所以请稍等一下。

是否存在依赖注入/控制反转的分层方法

3 个答案: