依赖注入容器、IOC容器 之 Service Locator 模式

总结：

我经常使用的Autofac，称为“IOC容器”，“依赖注入容器”，有三种注入服务的方式。在未读《ASP.NET Core 6 框架解密》前，只知道标准的注入方式是“构造函数”注入，后来知道了“Service Locator”模式。

Service Locator

1. 例如：使用Autofac时，会使用“ ILifeTimeScope ”的类似于Autofac容器的局部变量，可以通过“ ILifeTimeScope ”在动态运行时解析出需要的服务。
2. 例如：使用Asp.net Core中的“ IServiceCollection ”，在具体的方法中解析出服务。

　　如上述，这种使用的方式被称为 “Service Locator” 模式。

优点

　　使用Autofac，一个接口或者抽象类有多个实现类，在程序动态运行过程中根据指定的键解析出对应服务，这里使用就是“Service Locator”模式。参考 https://autofac.readthedocs.io/en/latest/advanced/keyed-services.html

缺点

　　我们使用服务时，都是IOC容器（或者说是框架）帮我注入服务，但使用“Service Locator”模式时，是应用程序在运行时，应用程序自己获取的服务，不是框架。

　　“Service Locator”模式，是“ 拉取 ”所需的依赖服务，依赖注入容器 “ 推送 ” 依赖的对象。

　　原文：本着 “ 松耦合 、高内聚 ”的设计原则，我们既然将一组相关的操作定义在一个能够复用的服务中，就应该尽量要求服务自身独立和自治。与此同时，服务之间应该具有明确的界定，服务之间的依赖关系应该是明确的而不是模糊的。无论是采用属性注入、初始化依赖服务的方法注入，还是Service Locator模式，都相当于引入一个新的依赖，对服务提供容器的依赖。

　　一个确定服务的依赖与容器的依赖在设计上是有本质区别的。前者是一种基于类型的依赖，无论是基于服务的接口还是实现类型，这都是一种基于“ 契约 ”的依赖。这种依赖不仅是明确的也是稳定的。但是容器是一个黑盒，对它 依赖不仅是模糊的也是不稳定的。

唉，真特么高兴，又搞清楚一个东西。