4.Autofac依赖注入初使用

前面几篇文章只是初步搭建项目结构，那到底能否运行呢？(能是肯定的啦)

毕竟咱都NetCore了，所以依赖注入要搞起来。专业的解释我就不多说了，很多博客文章说的很详细(其实是我忘了那些术语怎么讲)。

按照我的理解来说的话就是：

省的你自己手动new了，假如你要更改接口，那不就要每个new的地方都改一下？

松耦合，可重用，易维护。简单举例来说：我通过构造函数注入的是接口类，不直接依赖实现，所以你可以很方便的去更换实现，这不就松耦合了吗？可重用这个看个人需求吧，因为解耦彼此都是模块化的，独立的，所以可重用，维护也较为简单，对整个项目影响较小。

仓储模式本身的目的就是为了解耦合，模块化。

回想一下项目之间的彼此依赖关系：

1 仓储接口层定义接口类，仓储实现层引用仓储接口层实现具体内容。主要用于和数据库打交道。

2.1 服务接口层引用仓储接口层，主要用于调用仓储层对数据库进行交互。

2.2 服务接口层定义接口类，服务实现层引用服务接口层实现具体实现。主要处理业务逻辑。

3.1 API程序层引用服务接口层，接收前端的请求，主要调用服务层进行业务逻辑处理。

基本上就是这么一个流程。他们彼此之间是有直接或间接的依赖关系的。这些可能无法完全解耦......但实现层并未进行直接依赖，所以耦合性体现在这里~

回到文章一开始所说的:Autofac依赖注入！因为实现层还没有实际的包含进项目，所以我的做法是通过DLL程序集反射进行整个实现层的注入。还可以多个实现层注入，但是这点我没操作过，所以暂时就不说了，只是告诉你们这个可以做到~

这里我新建了一个类库:FastEasy.Common （公共类库）

主要就是添加一些多个地方会用到的东西，但是即便你不用也不影响的一些东西，比如这个autofac，微软也有自带的依赖注入可以选择，再比如日志，这个可选择的更多了，Nlog，Log4，serilog等等。我将这些搞到公共类库中，可以根据自己选择来使用，个人觉得比较方便一些~

本身我之前写过Autofac的教程，所以可能接下来会复制一些之前的......

引入Autofac包：Autofac.Extensions.DependencyInjection 包含了Autofac。
在Common公共类库添加Autofac相关的类，例如上面的截图，一眼就看出来这个是autofac相关的东西~

打开新建的AutofaModule类，继承Autofac的Module，敲override，重新antofac的Load加载方法~我直接贴代码了，代码有注释~~~

复制代码

        protected override void Load(ContainerBuilder builder)
        {
            //程序集目录
            var basePath = AppDomain.CurrentDomain.BaseDirectory;

            //仓储层服务层程序集路径
            var repositoryPath = Path.Combine(basePath, "FastEasy.Repository.dll");
            var servicePath = Path.Combine(basePath, "FastEasy.Service.dll");

            //加载程序集
            var repository = Assembly.LoadFrom(repositoryPath);
            var service = Assembly.LoadFrom(servicePath);

            //注入程序集
            builder.RegisterAssemblyTypes(repository, service)
                .AsImplementedInterfaces();
        }

修改程序默认的容器工厂。用Autofac覆盖它！Programs中配置

复制代码

        builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());//覆盖默认的容器工厂。
        builder.Host.ConfigureContainer<ContainerBuilder>(builder =>
        {
            builder.RegisterModule(new AutofacModule());
        });

最后一步可做可不做的操作：前面说过了，实现层没有直接引用，所以生成解决方案的时候是不包含仓储实现层和服务实现层的。这里有两个操作。
1. 第一个不用写代码，就是生成的时候把这两个dll丢到api下的bin文件夹里。
2. 第二张需要稍微配置一下实现层的 =》属性>生成>输出>输出的基路径: ..\FastEasyAPI\bin\

到这里就结束了，需要注意的点就是，如果修改了实现层，需要单独生成一下实现层，将其生成到发布路径下。

测试效果：我添加了一个测试用的Test控制器，包括其相应的仓储类服务类，并新增加减乘除接口。代码就不粘贴了，都是基础......就看一下接口的返回效果就好，看是否可以调用到仓储层返回结果

掰掰~