12. 依赖注入/控制反转
📝 模块更新日志
12.1 依赖注入
所谓依赖注入,是指程序运行过程中,如果需要调用另一个对象协助时,无须在代码中创建被调用者,而是依赖于外部的注入。
通俗来讲,就是把有依赖关系的类放到容器中,然后在我们需要这些类时,容器自动解析出这些类的实例。
依赖注入最大的好处是实现类的解耦,利于程序拓展、单元测试、自动化模拟测试等。
依赖注入的英文为:Dependency Injection,简称 DI
12.2 控制反转
控制反转只是一个概念,也就是将创建对象实例的控制权(原本是程序员)从代码控制权 剥离到 IOC 容器 中控制。
控制反转的英文为:Inversion of Control,简称 IOC
12.3 IOC/DI 优缺点
传统的代码,每个对象负责管理与自己需要依赖的对象,导致如果需要切换依赖对象的实现类时,需要修改多处地方。同时,过度耦合也使得对象难以进行单元测试。
-
优点
- 依赖注入把对象的创建交给外部去管理,很好的解决了代码紧耦合(tight couple)的问题,是一种让代码实现松耦合(loose couple)的机制
- 松耦合让代码更具灵活性,能更好地应对需求变动,以及方便单元测试
-
缺点
- 目前主流的
IOC/DI基本采用反射的方式来实现依赖注入,在一定程度会影响性能
- 目前主流的
特别说明
在本章节不打算细讲 依赖注入/控制反转 具体实现和应用场景,想了解更多知识,可查阅 【ASP.NET Core 依赖注入】 官方文档。
12.4 依赖 注入的三种方式
12.4.1 构造方法注入
目前构造方法注入是依赖注入推荐使用方式。
-
优点
- 在构造方法中体现出对其他类的依赖,一眼就能看出这个类需要依赖哪些类才能工作
- 脱离了 IOC 框架,这个类仍然可以工作
- 一旦对象初始化成功了,这个对象的状态肯定是正确的
-
缺点
- 构造函数会有很多参数
- 有些类是需要默认构造函数的,比如 MVC 框架的 Controller 类,一旦使用构造函数注入,就无法使用默认构造函数
- 这个类里面的有些方法并不需要用到这些依赖
代码示例:
public class FurionService
{
private readonly IRepository _repository;
public FurionService(IRepository repository)
{
_repository = repository;
}
}