设计原则：为什么需要“IOC”

背景知识

控制反转

反转传统的控制逻辑，常见的传统控制逻辑有：

一、客户类型负责创建依赖。反转后的结构是：由IOC负责创建。

二、客户类型调用框架。反转后的结果是：框架调用客户类型。

依赖注入

客户类型需要显式的声明其依赖，不要在客户类型中管理依赖的创建。

IOC

中文可以翻译为：控制反转容器或依赖注入容器。

参考资料

Inversion of Control Containers and the Dependency Injection pattern

InversionOfControl

设计原则：我是如何使用“依赖注入”的

.NET：在ASPX、ASHX和MVC中使用IOC容器（菜鸟必看）

DDD：管理“工作单元实例”的两种模式

为什么要使用IOC容器？

从对象的角度思考什么系统

系统是由一张对象图组合而成，这些对象通过彼此之间的协作（发送消息）来完成需求。概括如下：

系统 = 对象图 

基于类的语言如何表示系统

毫无疑问，在基于类的语言中：系统 = 类型定义 + 对象图（如何实例化）

考虑一个三层架构中的类图

如何创建这个类图的对象图？

简单的来说，我们有两种思路：

一、客户类型负责new依赖类型。这样做的结果是：

1. 1. 类图就是对象图，编译时绑定。
   2. 需要手工管理依赖的生命周期。
   3. 很难做单元测试。
   4. 很难升级和维护，比如：引入了一个新的子类，你要到处修改new的代码。

二、采用IOC容器new依赖类型。这样做的结果是：

1. 1. 类图不一定是对象图，运行时绑定。
   2. IOC容器挂自动管理的生命周期。
   3. 容易做单元测试。
   4. 容易升级和维护。

备注

有人说IOC的注册太麻烦，比new还麻烦，针对这个问题的思路是：“根据约定自动注册”，我就采用这种方式。