其他分享
首页 > 其他分享> > [.Net]使用Soa库+Abp搭建微服务项目框架(二):面向服务体系的介绍

[.Net]使用Soa库+Abp搭建微服务项目框架(二):面向服务体系的介绍

作者:互联网

上一章我们建立了一个典型的面向领域设计的Abp小项目,如果按照常规的开发方式,会遇到什么问题呢?

先来完善一下这个小项目,在定义好各实体类后,运行Miguration并向数据库里写入一些初始数据。

现在整个项目的依赖引用图如下,每一个都有独立的引用路线,互不干涉。

简略图如下

​假设现在有一个需求,MainService业务需要用到Service1和Service2 中的数据,如何操作?

在使用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,进行接口化改造

标签:Soa,服务,领域,Abp,Manager,Net,应用层,MainService
来源: https://www.cnblogs.com/jevonsflash/p/15806218.html