依赖注入

没那么复杂

很多时候我们会将问题复杂化，而问题的答案却一如既往的简单。

public class Stupid
{
    public IService Service { get; private set; }
    public Stupid()
    {
        Service = new ConcreteServiceA();
    }
}

public class Smart
{
    public IService Service { get; private set; }
    public Smart(IService service)
    {
        Service = service;
    }
}

上面是两段看上去极其相似的类型代码，区别在于 Service 属性的初始化。前者在创建类型实例的时候直接创建Service的实例，而后者则不同：

// 已经有了一个 IService 的实例引用：concrteServiceA
var smart = new Smart(concreteServiceA);

这就是 依赖注入（Dependency Injection，DI）。

当然，这只是依赖注入的其中一种形式，因为我们至少听说过以下三种形式的依赖注入： 构造函数注入、 属性注入、 方法注入。没错，按照前面的思路，属性注入就是给属性赋值，方法注入就是用指定的参数调用方法 —— 他们都是传递一些东西（一般是另一个对象的引用）给某个对象。

是什么在误导我们

站在过高的角度上去看问题，难免会看不透问题的本质。

我们接触 依赖注入，往往起源于某个 依赖注入框架(NInject，Autofac，Castle，Unity......)。从那时起我们开始在 依赖注入框架 划定的高度上入手 依赖注入。容器？注册？解析？......依赖注入框架为我们提供了丰富强大的功能，同时也带来了一大堆概念。然之后，我们还是没搞清楚依赖注入是什么，有什么优势，甚至开始怀疑它的可用性。

可是，整个圈子都在夸赞和使用的东西，怎么可能没有利用价值呢？ —— 把 依赖注入框架 当成 依赖注入，误导我们的，不是别人，是我们自己。

控制反转

说到依赖注入，就不得不提 控制反转（Inversion of Control，IoC）：作为设计模式六大原则之一，它不是具体技术，而是一种设计思想。

前文提到的 Stupid 类型，看上去也无伤大雅，很是美观易读。可是，IService 接口的设计初衷是什么呢？ Service 属性值的创建已经由 Stupid 类型的构造器完成了，IService 接口为我们带来的 多态性 在这个类里面俨然不复存在；属性值将随着 Stupid 类型实例的消逝而被回收，也不可能再被重复利用。在设计上，我们将这种情况称为 紧耦合 —— IService 接口成了摆设，ConcreteServiceA 与 Stupid 二者已是密不可分的存在。

显然，这是不合理的，我们需要改变 —— 将 Service 属性值的创建和生命周期管理交由 Stupid 类以外的地方去控制，就像 Smart 类型那样。

对的，这就是 控制反转。跟依赖注入一样，没那么复杂。

控制反转（IoC） VS 依赖注入（DI）

事实上这两者并没有什么可比性。记住一句话即可：控制反转 是一种设计思想，而 依赖注入 是 控制反转 的实现方式之一。没错，之一，因为 IoC 的实现方式不只是 DI。