.net core 注入机制与Autofac,.net core 注入中的三种模式:Singleton、Scoped 和 Transient

C#

浏览数:371

2019-5-8

AD:资源代下载服务

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

这里扯扯题外话:为什么要注入(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 提供的就是构造函数的注入方式。但注入还可以是属性的注入。属性注入就像是选择性依赖关系,而构造函数的注入就像是强制性依赖关系。(属性注入跟构造函数可以下次单独进行讨论)

作者:Vam8023