[.Net]使用Soa库+Abp搭建微服务项目框架(二):面向服务体系的介绍
上一章我们建立了一个典型的面向领域设计的Abp小项目,如果按照常规的开发方式,会遇到什么问题呢?
先来完善一下这个小项目,在定义好各实体类后,运行Miguration并向数据库里写入一些初始数据。
现在整个项目的依赖引用图如下,每一个都有独立的引用路线,互不干涉。
简略图如下
在使用Abp框架时,传统开发方式是先建立领域层服务,应用层中调用领域层服务(Manager)并返回给UI层,完成整个业务流程;或者更简单方式是直接在应用层注入仓储对象,拿到实体类做数据操作。
我们分别来完成这两个方式实现这一需求。
首先在MatoProject.MainService.Application项目中建立一个应用层服务MainService.cs并继承AsyncCrudAppService。
建立一个方法GetExtends,用于查询Entity1,Entity2 中的Type和Num字段。
方式1: 模拟传统方式在应用层获取数据:
看看依赖情况:
若是使用方式1, 在注入仓储对象的时候,势必直接引用了这两个服务的领域层,造成了耦合。
方式2: 模拟传统方式在领域层获取数据:
在Domain层中分别建立两个领域服务(Manager),并且定义GetType和GetNum方法,分别用于获取Entity1,Entity2 中的Type和Num字段
在MainService.cs的GetExtends方法更改分别调用两个Manager 的GetType与GetNum方法,从中获取Type和Num值。
拼接完成后返回结果
看看依赖情况:
若是使用方式2, 在注入领域服务(Manager)时,也势必直接引用了这两个服务的领域层,造成了项目之间的耦合
若是在MainService服务层应用了Service1 和 Service2 的话,则项目的各个模块边界将变得不明晰,上一章所讨论的依据上下文边界划分服务,也将变得没有意义。
简略图如下
现在,我们需要考虑用面向服务体系的架构改造,将MainService,Service1, Service2 解耦。
若要独立成服务,则要考虑引用其抽象,也就是要做接口化的改造,使其之间的状态变为弱关联
下一章节将介绍如何结合Abp,进行接口化改造
[.Net]使用Soa库+Abp搭建微服务项目框架(二):面向服务体系的介绍