.net程序开发IOC控制反转和DI依赖注入详解

大部分应用程序都是这样编写的：编译时依赖关系顺着运行时执行的方向流动，从而生成一个直接依赖项关系图。 也就是说，如果类 A 调用类 B 的方法，类 B 调用 C 类的方法，则在编译时，类 A 将取决于类 B，而 B 类又取决于类 C

应用程序中的依赖关系方向应该是抽象的方向，而不是实现详细信息的方向。而这就是控制反转的思想。

应用依赖关系反转原则后，A 可以调用 B 实现的抽象上的方法，让 A 可以在运行时调用 B，而 B 又在编译时依赖于 A 控制的接口（因此，典型的编译时依赖项发生反转）。 运行时，程序执行的流程保持不变，但接口引入意味着可以轻松插入这些接口的不同实现。

上下不同的实现方式在于之前的依赖关系是A->B->C，控制反转后A->B接口->C接口，然后具体的B,C实现又是B->B接口 的反转依赖。这样的好处就是A只依赖B接口而不是依赖实现，具体我们要实现什么只需要按照业务需求进行编写，并且可以随时替换实现而不会影响A的实现，这种思想就是控制反转。

如下是顺序依赖：

1. public class A 
2. { 
3. //依赖具体类 
4. public B b; 
5. public C c; 
6. public A(B _b, C _c) { 
7. b = _b; 
8. c = _c; 
9. } 
10. public void Listen() 
11. { 
12. b.SayHi(); 
13. c.SayBye(); 
14. } 
15. } 
16. public class B 
17. { 
18. public void SayHi() 
19. { 
20. Console.WriteLine("hi..."); 
21. } 
22. } 
23. public class C 
24. { 
25. public void SayBye() 
26. { 
27. Console.WriteLine("bye..."); 
28. } 
29. } 

如下是控制反转：

1. public class A 
2. { 
3. //依赖接口 
4. public IB b; 
5. public IC c; 
6. public A(IB _b, IC _c) 
7. { 
8. b = _b; 
9. c = _c; 
10. } 
11. public void Listen() 
12. { 
13. b.SayHi(); 
14. c.SayBye(); 
15. } 
16. } 
17. public interface IB 
18. { 
19. public void SayHi(); 
20. } 
21. public interface IC 
22. { 
23. public void SayBye(); 
24. } 

DI依赖注入

.NET 支持依赖关系注入 (DI) 软件设计模式，这是一种在类及其依赖项之间实现控制反转 (IoC) 的技术。我们首先用代码来看什么是DI，在.net提供的扩展包Microsoft.Extensions.DependencyInjection中来完成DI,nuget安装。

然后我们实现接口B和接口C,实现我们可以说英语，也可以说汉语，我们在SayHi和SayBye中输出汉语。

1. public class B : IB 
2. { 
3. public void SayHi() 
4. { 
5. Console.WriteLine("你好..."); 
6. } 
7. } 
8. public class C : IC 
9. { 
10. public void SayBye() 
11. { 
12. Console.WriteLine("再见..."); 
13. } 
14. } 

然后在服务容器中注册依赖关系。 .NET 提供了一个内置的服务容器 IServiceProvider。 服务通常在应用启动时注册，并追加到 IServiceCollection。 添加所有服务后，可以使用 BuildServiceProvider 创建服务容器，然后在容器中直接“要”对象而不用去管它如何实例化，并且DI具备传染性，假如B引用了D接口ID，那么我们注册B并在获取B实例时，引用的D接口也会被实例化。

1. //IServiceCollection 服务 
2. IServiceCollection services = new ServiceCollection(); 
3. //服务注册 
4. services.AddTransient<A>(); 
5. services.AddTransient<IB, B>(); 
6. services.AddTransient<IC, C>(); 
7. //创建服务容器 
8. var serviceProvider = services.BuildServiceProvider(); 
9. //获取服务 
10. var a = serviceProvider.GetRequiredService<A>(); 
11. //使用 
12. a.Listen(); 
13. Console.ReadKey(); 

这就是通过DI依赖注入的方式来实现IOC的思想，或许你会好奇为什么我们不直接实例化A,然后在构造方法里面传进去就行了，也就不依赖DI实现了。但是程序结构更复杂些呢，比如上面提到的B又有D,D又有F呢，这样在构造的时候不是一直要new很多对象，而且同一个接口的不同实现还要去找实例化处的代码进行修改。例如SayHI我想说英文呢？那么我们就可以实现一个BB,然后在服务注册的地方注册BB就可以了。

1. public class BB : IB 
2. { 
3. public void SayHi() 
4. { 
5. Console.WriteLine("hello..."); 
6. } 
7. } 

替换注册BBservices.AddTransient<IB, BB>(),而不用去改任何逻辑。

服务生命周期

在注册服务的时候我使用的AddTransient方法，表示注册的服务是瞬态的，也就是每次请求都是重新创建实例。同时还提供其它注册服务的方法。

服务有三种声明周期：

瞬态

作用域

单例

• 瞬态

服务是每次从服务容器进行请求时创建的。 这种生存期适合轻量级、 无状态的服务。 用 AddTransient 注册服务。在处理请求的应用中，在请求结束时会释放暂时服务。

• 作用域

指定了作用域的生存期指明了每个客户端请求（连接）创建一次服务。 向 AddScoped 注册范围内服务。在处理请求的应用中，在请求结束时会释放有作用域的服务。

想asp.net 在处理一个请求的时候是一个作用域，同样我们自己也可以定义作用域。使用serviceProvider.CreateScope()创建作用域，在作用域释放后对象将被释放。

我们使用AddScoped添加对象，然后在作用域中取两个A对象进行比较，可以看到是True。

如果我们用AddTransient注册A,即使在作用域内两个对象比较也是不一样的，结果为False。

• 单例

单例大家应该好理解，就是设计模式中的单例，使用AddSingleton 注册，在首次请求它们时进行创建；或者在向容器直接提供实现实例时由开发人员进行创建。 很少用到此方法，因为可能是线程不安全的，如果服务中有状态。

其它

在Microsoft.Extensions.DependencyInjection中只能用构造函数注入，其它框架还提供属性注入，比如autofac。至于原因不得而知，当然也看个人喜好。查了些资料说是构造函数注入更科学，在对象创建的瞬间对象的构造方法将服务实例化，避免逻辑问题。