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

DI/IOC：有很多框架，并且这些示例很快就会被粘贴到特定于该框架的细节中。我发现，如果我能够在框架之外学习其原理（树木遮蔽树木），我通常会学到最好的新技术。是否存在分层方法来控制依赖注入/控制反转

我的问题：DI/IOC的简单原则是什么？我正在寻找一种（框架不可知的）构建方法，其中概述了每种简单原理所获得的成果，选择的成本以及成本。请不要粘贴链接，除非他们真正解决我的问题。我一直在那些森林迷路;}

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

在此先感谢！罗伯特

来源

2009-06-15 RAL

我非常快速和肮脏对其采取

依赖注入控制反转并不同样的事情。控制反转使用 DI。
IoC是一种在运行时将应用程序拼接在一起而不是编译时间的方式。
而不是在代码中'新建'一个类型，它在运行时由IoC容器注入。
IoC容器知道要注入什么类，因为a）它查看该类的构造函数 - 所有参数都是接口。 b）它会查看它的配置文件，并查看实现了每个接口的哪些类用于在应用程序中表示该接口。

这里是一个非常简单的例子

比方说，你有一个接口IEmailer用于发送电子邮件：

public interface IEmailer 
{ 
    void SendEmail(); 
}

而且至少有一个实现这个接口：

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

您在IoC容器的con中定义图文件（在某种程度上）：

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的全部概念。

来源

2009-06-18 19:40:48

这是一个有点过时，但很好地概括Inversion of Control

对我来说，推动国际奥委会基本原则是组件，模块化，松耦合，凝聚力的概念。这意味着您可以设计分解为具有清晰依赖关系的连贯模块化单元的软件，或与其他单元的链接。这是任何领域工程的基本原则，而不仅仅是编程。一旦你具有模块性，为了创建一个功能系统，你需要一种方法来链接这些组件，以便它们形成一个功能整体。 IoC/DI框架是抽象这种链接概念的组件，并允许您编写声明组件之间链接的代码，然后有能力执行这些链接。 “反转”部分来自这样一个事实，即组件本身不再链接到它们的依赖关系，而是由链接组件在外部执行链接。这又被称为依赖注入。典型的IoC/DI框架允许您编写指定另一个组件所依赖的接口的特定实现的代码，然后允许您实例化该组件，并在创建时由IoC容器提供所需的实现。然后这抽象了对象创建的概念。

来源

2009-06-15 19:28:40 eulerfx

您的问题需要一份完整的维基百科文章。我假设你已经阅读过关于实际文章的内容，所以这里是我对你的问题的简短回答：依赖注入就是关于实例化。

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

这使您可以编写出类：

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

要回答你的第二个问题：如果你想学习约 DI，然后写一个框架，自己显然是矫枉过正。我会建议你选择一个流行的开源框架并编写代码来消耗它 - 大多数都有很好的教程来达到这个目的。

把它提升到一个新的水平，你可以获得你正在使用的框架的源代码并开始挖掘它。良好的框架写得很好，相对容易阅读。

祝你好运！ urig

PS - 如果您使用.net，请不要以MEF开头。从Windsor，Unity或Spring.Net开始。 MEF不仅仅是一个DI框架，所以稍后再做。

来源

2009-06-18 19:25:12 urig

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

回答

相关问题