依赖注入 - 口语解释

Question

最近我被要求用口语解释表达DI。

我回答：

1） 我要去酒店。我点了食物。酒店管理层要我清理盘子 清理表。所以我在这里是一个客户端，我负责管理服务（实例化，执行，处理）。但DI解耦这些任务，所以服务消费者不必担心控制服务的生命周期。

2） 他还问过是否有任何微软API跟随DI？。我回答（这是我的猜测）在WCF中，您可以使用控制工厂生命周期的ChannelFactory创建代理。

对于第（1）项，他说只有10％是正确的

对于第（2）项，他说工厂模式不是依赖注入。

实际上我的解释出了什么问题（除了我糟糕的英语）？那些人的真正答案是什么？

我在等你宝贵的建议。

Answer 1

1。

我认为在你的酒店示例中，它更像是你出现在吃饭，你被要求先建造厨房，塑造盘子，碗和餐具，建造桌子和椅子，种植小麦和蔬菜，屠宰和屠宰肉，然后煮饭和清理。

我的例子是手术/手术。外科医生的责任是执行手术。而已。她没有制作手术器械，也没有从柜子里取出所有器械。当她出现进行手术时，所有的工具都排成一行并为她准备好 - 它们是从外面提供的，外科医生不关心或者不需要知道是谁把它们放在那里，只要它们可用并且在她需要工作时做好准备。

同样在给定的类中，依赖项注入意味着该类依赖于其工作的任何其他组件应该作为参数“注入”到构造函数，或者通过在实例化类时设置属性。该课程不关心发现或创造这些东西。

2

我已经提到过Microsoft Patterns＆amp;实践/企业库支持使用Unity应用程序块（控件反转容器）进行DI，并且认为 ASP.NET MVC库使用DI。

Answer 2

我认为你的第一个答案是相当的，尽管它当然可以详细说明。它让我想起Stack Overflow上的one of my favorite answers。

在我看来，最重要的DI模式是构造函数注入，但实际上很难在BCL中找到示例。

但是，System.IO.StreamWriter就是一个例子。在许多构造函数中，它有这个：

public StreamWriter(Stream stream);

由于Stream是一个抽象类，它完全符合依赖关系的描述，并且注入到StreamWriter中。

您的WCF示例是一个抽象工厂。这是一个非常重要的与DI相关的模式，但不是DI本身。

Answer 3

我认为“口语”可能意味着使用非技术语言来描述，而不是给出一个真实世界的例子。所以：

1. 依赖注入允许用户提供自己的问题解决方案，并将其与预构建的系统集成。我现在想不出现实世界的类比。

2. 想想一个接受接口作为参数的框架方法，你可能有一个依赖注入的例子。我想Linq命名空间中有很多例子。