正文

.net core 注入机制与Autofac

IP云
IP云V管理员/4 阅读
12/02
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

本来是要先出注入机制再出 管道 的，哈哈哈……就是不按计划来……

这里扯扯题外话：为什么要注入（DI，dependency-injection），而不用 new 对象？

可能我们都很清楚，new 对象所造成的影响就是耦合度太高，DI 就是用来解耦的。或者还可以说，DI 可以统一进行管理对象。

此话怎讲呢？

这里还要扩展一下，讲一下接口（Interface）跟类（Class）：

接口的话通常都像 IDisposable、IEnumerable 或者 ICollection 这些一样以 " I " 开头命名的；而类就是继承并实现这些接口的（当然，类不一定要继承），比如 List 或者 Map。他们两个都有可能是 IEnumerable 的实现，因为他们都是多继承的实现类。

所以说，通常我们的类都是依赖于其他的。比如说我们有个 Database 的类（当然日志也行是吧），这个类主要是连接数据库的。然后呢，这个类里面，可能要做一下记录，比如数据库是否连接失败呀，那么就要在这个类里面实例化另外一个 Logger 的类（平时的业务功能代码实现是不是都像这样，哈哈哈）。那么在 Database 类里面实例化了 Logger 类，它们之间就存在了依赖关系（Database 依赖 Logger）。 

    public class Database

    {

        public void DoSomething()

        {

            var logger = new Logger();

        }

    }

这代码没毛病，但是如果突然有个需求说，我们的 Logger 不记录在本地，我要通过 TCP/IP 记录到另外一台服务器上。哈，我们是不是要改代码了……

如果我们不希望改动 Logger 里面的代码，那么我们就创建多一个 TcpLogger ，那么是不是要在项目中将所有的或者需要使用到 TcpLogger 的 Logger 类进行替换。 

    public class Database

    {

        public void DoSomething()

        {

            //var logger = new Logger();

            //替换成

            var logger = new TcpLogger();

        }

    }

这方法有点蠢吧，第一，没啥意思；第二，很容易出现错误，改动的地方越多，就越容易出错；第三，有点傻，重复去做这些没啥意思的事情，如果下次再换一种日志方式，岂不是又要改一遍？!

理解设计模式的人，很容易想到工厂模式了吧，最常用的。（但，在讲注入，扯到设计模式，是不是跑题啦……）

设计模式大概怎么搞？ 

            ICanLog logger = new Logger();

熟悉啵，只要继承 ICanLog 并且实现它，我们要什么就 new 什么。但这样同样是 new 实例的方式，也没有做到，我要是换一种方式记录日志，还是要改代码呀。我就是忒不想改代码的。那就试试换一种： 

            ICanLog logger = LoggerFactory.Create();

            //或者

            ICanLog logger = TypeFactory.Create<ICanLog>();

这也超级熟悉的是不是。嗯，好像是要换什么日志方式，就去改类型工厂。改的少的，但是不是有可以不改代码的方式？

肯定是有的！我们可以通过映射（mapping）进代码里面。但如果在代码里面进行映射，还是要进行编译。那如果把映射关系放到 XML 文件里面，就不用重新编译啦。在开发中，是体会不了这种爽的。举个栗子：

在生产环境中，如果某些原因，其中一个正在 Log 的功能运转不了了，但是可以使用另外一种方式进行 Log，我们是不是更新一下 XML 配置文件，替换一下就可以。（千万别把改配置跟改代码混为一谈，完全不同！本质区别！）

OK，这里通过 XML 配置文件进行映射的功能，换个概念 -- IoC（Inversion of Control，控制反转），什么意思？ 

since you invert control over who decides what exact class to instantiate.

简而言之，你控制你所要使用的实例，就是通过（配置）控制转化你所要使用的类实例。

上面所说的其实跳过了很多很多，就是怎么实现这种映射，代码中有怎么决定使用哪一个实例呢？还是用日志举例：就是你本来就已经写好了两种日志的模式，你的配置只是确定你要使用哪一种日志模式而已，我们就可以当成这种是一种服务的定位器（就是确定我要使用的服务）。

现在的话，我们的代码已经不再是 Logger 类了，而且依赖于这个配置。

往回看一下日志工厂或类型工厂的创建实例的过程，那么注入的下一步就是获得注入的实例，看代码： 

        public Database(ICanLog logger) {

        }

见鬼啦，.net core 里见得多了吧。当然，我们现在仍然是不知道到底怎么注入的，注入的过程是怎么样的，但我们已经知道为什么要用注入了。

终于要进入主题啦 -- .net core 注入机制（.net core 提供了一个内置的服务容器 IServiceProvider，服务已在应用的 Startup.ConfigureServices 方法中注册）：引入了 Conforming Container 机制，包含了请求生命周期作用域, 服务注册等等的统一概念。

看图，看完就讲完了，哈哈哈……其实图中没有将服务的生命周期画出来，可以去《.net core 注入中的三种模式：Singleton、Scoped 和 Transient》看服务容器 IServiceProvider 负责管理服务的过程。这里补重复码字。

上图中，我们看到一个容器，是 .net core 提供的一个容器，用来管理所注入的服务的。那么既然有了一个容器，我们为什么要在这篇里面讲 Autofac？Autofac 是什么？

Autofac 是一款 Ioc 容器！

在 .net core 使用 Autofac ，我将它理解为容器的扩展与补充。（咦，可以来一篇 Autofac 的个人秀哟）

1、.net core 没有能处理每个请求特定的作用域；

2、.net core 相比 Autofac，后者维护起来更方便（maintainability）、可读性更强（readability），没那么容易混淆；

3、后续继续总结！

.net core 与 Autofac 除了这些之外，它们之间只是选择而已！

PS：.net core 提供的就是构造函数的注入方式。但注入还可以是属性的注入。属性注入就像是选择性依赖关系，而构造函数的注入就像是强制性依赖关系。（属性注入跟构造函数可以下次单独进行讨论）

相关阅读

目录[+]