.Net Core中使用Autofac替换自带的DI容器的示例

为什么叫浅谈呢？就是字面上的意思，讲得比较浅，又不是不能用（这样是不对的）！！！

aufofac大家都不陌生了，说是.net生态下最优秀的ioc框架那是一点都过分。用的人多了，使用教程也十分丰富，官网教程也比较详细（如果英文功底还不错的话）。

那我为什么还要写这样一篇博客呢，一是用作学习笔记，二就是闲的。

废话不多说，开始正文

项目创建

云创建一个.net core api项目，然后再添加一个类库，大概就是下面这样的结构：

新建一个类库项目，分别添加一个接口文件与类文件：

就这样，我们的演示方案就搭建完成了，下面就到了演示阶段。

方案演示

原始方案

俗话说的好，没有对象 new 一个就对了：

[httpget]
public string original()
{
    iuserservice userservice = new userservice();
    return userservice.getname("original");
}

结果当然是没问题的：

.net core自带di

微软给我们提供的 di 解决方案。如果是小项目，需要注入的服务不多，简直无敌好用，缺点就是不能批量注入，下面我们来复习一下：

先在 startup 里面的 configureservices 方法内注入（默认且只能构造函数注入）

services.addscoped<iuserservice, userservice>();

然后在控制器中拿到刚才注入的服务：

 public class defaultcontroller : controllerbase
  {
      private readonly iuserservice userservice;
      public defaultcontroller(iuserservice _userservice)
      {
          this.userservice = _userservice;
      } 
     [httpget]
     public string coredi()
     {
         return userservice.getname("coredi");
     }
 }

很显然，一点问题都没有：

autofac

注意事项说在前面：

在 .net core2 中一般是把startup的configureservices方法返回值类型改为iserviceprovider，然后通过构建autofac容器并注入服务后返回。

在 .net core3.0之后，集成方式做了部分调整

下面演示的版本是.net core 3.1，也就是调整后的版本。

1、先引用 autofac 的包，看看这下载次数

2、在 program 中改用 autofac 来实现依赖注入

public static ihostbuilder createhostbuilder(string[] args) =>
    host.createdefaultbuilder(args)
        // 就是这句
        .useserviceproviderfactory(new autofacserviceproviderfactory())
        .configurewebhostdefaults(webbuilder =>
        {
            webbuilder.usestartup<startup>();
        });

3、添加我们自定义的 autofac 注册类，并注册我们需要的服务（默认构造函数注入，支持属性注入）

public class autofacmoduleregister : autofac.module
{
    //重写autofac管道load方法，在这里注册注入
    protected override void load(containerbuilder builder)
    {
        builder.registertype<userservice>().as<iuserservice>();
　　 }
}

4、在 startup 类中添加方法：configurecontainer，

public void configurecontainer(containerbuilder builder)
{
    // 直接用autofac注册我们自定义的 
    builder.registermodule(new autofacmoduleregister());
}

5、大功告成，控制器内的方法甚至不用去改

public class defaultcontroller : controllerbase
 {
     private readonly iuserservice userservice;
     public defaultcontroller(iuserservice _userservice)
     {
         this.userservice = _userservice;
     }

     [httpget]
     public string autofac()
     {
         return userservice.getname("autofac");
     }
 }

演示到这里就结束了，是不是感觉 autofac 比自带的 di 还要麻烦。其实不然，下面我们就来看看 autofac 对比自带 di 的一些特有特性。

不同的特性

批量注入

之前的项目我们有了用户 userservice，需求更新，加入了商品（productservice），有了商品那又怎么能少得了订单（orderservice），那后面是不是还得有售后、物流、仓库、营销......

如果是.net core 自带的注入框架，那就只能不停的：

services.addscoped<iproductservice, productservice>();
services.addscoped<iorderservice, orderservice>();
......

这时候，autofac 的好处就体现出来了：批量注入。

我们先回到上面的：autofacmoduleregister 类，加入下面这段代码：

// 服务项目程序集
assembly service = assembly.load("xxx.service");
// 服务接口项目程序集
assembly iservice = assembly.load("xxx.iservice");
builder.registerassemblytypes(service, iservice)
    .where(t => t.fullname.endswith("service") && !t.isabstract)
    .instanceperlifetimescope()
    .asimplementedinterfaces();

上面的代码就是批量注入 xxx.service 与 xxx.iservice 项目下的服务与接口。

注意：如果需要注入的服务没有 interfac ，那么builder.registerassemblytypes 就只需要传一个程序集就ok了。如果服务与接口同在一个项目，那也是要传两个程序集的哦。

然后我们在控制器去通过构造函数获取注入的实例：

private readonly iuserservice userservice;
private readonly iproductservice productservice;

public defaultcontroller(iuserservice _userservice, iproductservice _productservice)
{
    this.userservice = _userservice;
    this.productservice = _productservice;
}

再对之前的 autofac 接口添油加醋：

[httpget]
public string autofac()
{
    var name = userservice.getname("autofac");
    return productservice.buy(name, "批量注入");
}

结果自然是没有问题的，如果后续需要加入其它服务都不用再单独注入了，是不是优点就体现出来了。批量注入还有一些其它的玩法，比如筛选类名，筛选父类等。

属性注入

.net core 自带的 di 框架与 autofac 默认都是构造函数注入，官方建议也是构造函数注入。

但是有些同学可能就不喜欢构造函数注入，再加上有些场景确实不适合构造函数注入（比如基类实体），所以 autofac 也支持属性注入，下面我们来看看使用方法，在之前批量注入的基础上，我们简单改造一下：

assembly service = assembly.load("autofac.service");
assembly iservice = assembly.load("autofac.service");
builder.registerassemblytypes(service, iservice)
    .where(t => t.fullname.endswith("service") && !t.isabstract)
    .instanceperlifetimescope()
    .asimplementedinterfaces()
    .propertiesautowired(); // 属性注入

对比构造函数注入，属性注入就多追加了propertiesautowired() 函数，控制器内修改：

public iuserservice userservice { get; set; }
public iproductservice productservice { get; set; }

注意：属性注入记得将属性的访问修饰符改为注册类可访问的修饰符，否则会注入失败。

下面我们来看看使用效果：

咦，怎么会空引用呢？原因大概就是 controller 是由mvc 模块管理的，不在 ioc 容器内，所以在 controller 中无法使用 autofac 注入的实例。

那为什么构造函数注入的时候又可以呢？大概或许可能他们都是构造函数注入吧...

为什么是大概呢？因为我暂时也没有具体去深入研究到底是什么原因导致的，如果有一天，我想起来去研究了并且有结果了，我会在这里补上。

我们先解决上面的问题先，在 startup 的 configureservices 方法底部加入如下代码：

// 使用 servicebasedcontrolleractivator 替换 defaultcontrolleractivator；
// controller 默认是由 mvc 模块管理的，不在 ioc 容器中。替换之后，将放在 ioc 容器中。
services.replace(servicedescriptor.transient<icontrolleractivator, servicebasedcontrolleractivator>());

然后回到我们的autofacmoduleregister 注入 controller：

builder.registertypes(getassemblytypes<startup>(type => typeof(controllerbase).isassignablefrom(type)))
                .propertiesautowired();

这样处理完后，属性注入就ok了。

存储并提取容器实例

我们在之前项目的基础上添加两个项目 common 与 entities，存放公共类与实体类。

我们需要在实体类里面使用到 common 项目中的某个类，结构如下：

// 基类实体　　 public class baseentity
    {
        public class1 common_class1 { get; set; }

        public string createid { get; set; }

        public void create()
        {
            this.createid = common_class1.getcurrentuserid();
        }
    }
    // 公共类
    public class class1
    {
        public string getcurrentuserid()
        {
            return guid.newguid().tostring();
        }
    }

从上面的接口中我们可以看到，我需要将 class1 通过属性注入到容器中：

builder.registertype<class1>().propertiesautowired().instanceperlifetimescope();

我们先在 controller 中看看效果：

public class1 class1 { get; set; }

[httpget]
public string autofac()
{
    return class1.getcurrentuserid();
}

很显然结果是没问题的：

那我们再到 baseentity 中去试试看：

咦，又出现空引用，注入失败了。其实这个问题很明显，我们使用的是 new 来实例化的 baseentity对象，没有遵循容器实例使用规则，自然就无法使用容器中的实例了。

大家可以自己试一下，将 new 改为属性注入就没问题了，但是这种方案并不友好，下面要说的是另一种方案。

我们再新添加一个公共类：containerhelper，并声明一个属性用来存储容器的实例：

public static class containerhelper
{
    public static ilifetimescope containerbuilder { get; set; }
}

然后回到 startup 中，在configure 方法的底部加入如下代码：

containerhelper.containerbuilder = app.applicationservices.createscope().serviceprovider.getautofacroot();

再回到实体类中去使用：

public void create()
{
    if (common_class1 == null)
    {
        using (var scope = containerhelper.containerbuilder.beginlifetimescope())
        {
            common_class1 = scope.resolve<class1>();
        }
    }
    this.createid = common_class1.getcurrentuserid();
}

autofac 的替换方案暂时就写到这里了，后续如果有新的理解或心得会再做修改，浅谈嘛就真的是浅谈，有错误或补充的地方请大家不吝赐教。

源码这里就不提供了，大家有耐心的可以跟着手敲一遍，虽然对理解没啥作用，但能使记忆更深刻一点。

到此这篇关于.net core中使用autofac替换自带的di容器的示例的文章就介绍到这了,更多相关.net core autofac替换di容器内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！