最近有人要求我用口语解释来表达DI。
我回答：
1) 我要去一家酒店。我点了食物。酒店管理人员让我清理盘子和 清理表格。所以这里我是客户，我负责管理服务（实例化、执行、处置）。但是 DI 将这些任务解耦，因此服务使用者无需担心控制服务的生命周期。 em>
2) 他还问是否有任何微软 API 遵循 DI ？我回答（这是我的猜测）在 WCF 中，您可以使用 ChannelFactory 创建一个代理来控制工厂的生命周期。
对于第 (1) 项，他说只有 10% 是正确的
对于第（2）项，他说这是工厂模式而不是依赖注入。
实际上我的解释出了什么问题（除了我的英语不好）？这些问题的真正答案是什么？
期待您的宝贵建议。
【问题讨论】：
标签： c# asp.net dependency-injection
我认为在您的酒店示例中，更像是您出现在吃饭时，您被要求首先建造厨房，制作盘子、碗和器皿，建造桌子和椅子，种植小麦和蔬菜，屠宰和屠宰肉，然后煮饭和清理。
我的例子是手术/手术。外科医生的职责是进行手术。而已。她不制造手术器械，也不去柜子里收集它们。当她出现进行手术时，所有工具都已排好并为她准备就绪——它们是从外部提供的，外科医生不在乎或不需要知道是谁把它们放在那里的，只要它们可用并在她需要工作时做好准备。
同样，在给定的类中，依赖注入意味着该类所依赖的任何其他组件都应作为构造函数的参数或通过在实例化类时设置属性来“注入”。该类不关心查找或创建这些东西。
我已经提到 Microsoft 模式和实践/企业库支持带有 Unity 应用程序块（控制反转容器）的 DI，我认为 ASP.NET MVC 库使用 DI。
【讨论】：
我认为您的第一个答案很准确，尽管当然可以详细说明。它让我想起了 Stack Overflow 上的one of my favorite answers。
在我看来，最重要的 DI 模式是构造函数注入，但实际上很难在 BCL 中找到示例。
不过，System.IO.StreamWriter 就是一个例子。在众多的构造函数中，有这样一个：
public StreamWriter(Stream stream);
由于 Stream 是一个抽象类，它非常适合对依赖项的描述，并且它被注入到 StreamWriter 中。
您的 WCF 示例是一个抽象工厂。这是一个与 DI 相关的非常重要的模式，但与 DI 本身无关。
【讨论】：
我认为“口语”可能意味着使用非技术语言进行描述，而不是给出一个真实世界的例子。所以：
依赖注入允许用户提供自己的问题解决方案并将其与预构建系统集成。目前我想不出一个与此类似的现实世界。
想想一个接受接口作为参数的框架方法，你可能有一个依赖注入的例子。我想在 Linq 命名空间中有很多例子。
【讨论】：