4.Autofac依赖注入初使用

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

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

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

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

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

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

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

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

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

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

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

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

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


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

4.Autofac依赖注入初使用

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

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

  1. 引入Autofac包:Autofac.Extensions.DependencyInjection  包含了Autofac。

    4.Autofac依赖注入初使用

  2. 在Common公共类库添加Autofac相关的类,例如上面的截图,一眼就看出来这个是autofac相关的东西~
  3. 打开新建的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();         } 

  4. 修改程序默认的容器工厂。用Autofac覆盖它!Programs中配置
            builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());//覆盖默认的容器工厂。         builder.Host.ConfigureContainer<ContainerBuilder>(builder =>         {             builder.RegisterModule(new AutofacModule());         });

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

      4.Autofac依赖注入初使用

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


 

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

4.Autofac依赖注入初使用

 

 掰掰~

 

发表评论

相关文章

当前内容话题