前面几篇文章只是初步搭建项目结构,那到底能否运行呢?(能是肯定的啦)
毕竟咱都NetCore了,所以依赖注入要搞起来。专业的解释我就不多说了,很多博客文章说的很详细(其实是我忘了那些术语怎么讲)。
按照我的理解来说的话就是:
省的你自己手动new了,假如你要更改接口,那不就要每个new的地方都改一下?
松耦合,可重用,易维护。简单举例来说:我通过构造函数注入的是接口类,不直接依赖实现,所以你可以很方便的去更换实现,这不就松耦合了吗?可重用这个看个人需求吧,因为解耦彼此都是模块化的,独立的,所以可重用,维护也较为简单,对整个项目影响较小。
仓储模式本身的目的就是为了解耦合,模块化。
回想一下项目之间的彼此依赖关系:
1 仓储接口层定义接口类,仓储实现层引用仓储接口层实现具体内容。主要用于和数据库打交道。
2.1 服务接口层引用仓储接口层,主要用于调用仓储层对数据库进行交互。
2.2 服务接口层定义接口类,服务实现层引用服务接口层实现具体实现。主要处理业务逻辑。
3.1 API程序层引用服务接口层,接收前端的请求,主要调用服务层进行业务逻辑处理。
基本上就是这么一个流程。他们彼此之间是有直接或间接的依赖关系的。这些可能无法完全解耦……但实现层并未进行直接依赖,所以耦合性体现在这里~
回到文章一开始所说的:Autofac依赖注入!因为实现层还没有实际的包含进项目,所以我的做法是通过DLL程序集反射进行整个实现层的注入。还可以多个实现层注入,但是这点我没操作过,所以暂时就不说了,只是告诉你们这个可以做到~
这里我新建了一个类库:FastEasy.Common (公共类库)
主要就是添加一些多个地方会用到的东西,但是即便你不用也不影响的一些东西,比如这个autofac,微软也有自带的依赖注入可以选择,再比如日志,这个可选择的更多了,Nlog,Log4,serilog等等。我将这些搞到公共类库中,可以根据自己选择来使用,个人觉得比较方便一些~
本身我之前写过Autofac的教程,所以可能接下来会复制一些之前的……
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(); }
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());//覆盖默认的容器工厂。 builder.Host.ConfigureContainer<ContainerBuilder>(builder => { builder.RegisterModule(new AutofacModule()); });
到这里就结束了,需要注意的点就是,如果修改了实现层,需要单独生成一下实现层,将其生成到发布路径下。
测试效果:我添加了一个测试用的Test控制器,包括其相应的仓储类服务类,并新增加减乘除接口。代码就不粘贴了,都是基础……就看一下接口的返回效果就好,看是否可以调用到仓储层返回结果
掰掰~