.net core 注入机制与Autofac

时间：2019-04-26 11:04:55 阅读：134 评论：0 收藏：0 [点我收藏+]

标签：plog 处理决定方式 control config 过程 arp 定位器

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

这里扯扯题外话：为什么要注入（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 机制，包含了请求生命周期作用域, 服务注册等等的统一概念。

技术图片