文档章节

SOA四层架构中的服务层设计

潜化
 潜化
发布于 2016/08/14 21:31
字数 1395
阅读 476
收藏 8

最近在做的项目,电商平台中的商品服务,属于电商平台中最基础的服务。项目整体架构——SOA服务治理的方式。这个项目属于重构项目,由php重构为java。自己在项目中的角色coder+架构吧。

项目的层次结构四层,export(对外暴露的dubbo接口)、facade(业务归集)、service(具体业务)、dao(数据持久)。按道理说的很清楚,但是每个人都对这四层架构有各自的理解,实现就不太理想了。

开始大家各写各的接口,每个接口都有自己的sql,自己的service,各种model实体类,facade只是一个空壳,代码完全不复用。老实说当时写的很痛苦,我希望的结果是dao层和service层是基础接口,能够复用,划分好领域对象,每一层只操作自己的领域对象。跟同事争论了很久,也跟项目经理讨论过。为了赶进度,大家都没有在意。最后项目经理看了下代码,发现写的非常烂,又在一起讨论了下。最终决定service和dao按我说的方式重新开发,然后让我一个人开发。

因为以前做的项目都是小项目,而正在做的项目又属于业务复杂,数据量巨大的项目。写代码的时候还是遇到了很多问题、项目也接近尾声。就把做项目时的一些想法简单的罗列下。

1、定义service接口时,最重要也是最先做的是定义service实体。通过service实体要能体现出业务对象之间的关系,该实体为项目所属领域的实体,如果系统业务复杂,定义该实体一定要和同事和leader讨论下。

2、虽然理论上service层的model和表应该没有对应关系。但是为了避免过多的对象转换,我觉得service实体可以体现出表与表关系。mybatis可以直接映射到该实体。这种实体我之前的项目会加DO后缀,可以理解为Domain Object,也可以理解为 Dao Object,它包括数据表的所有字段和一些业务字段,作用域只限于Service和Dao。

3、service层提供的方法首先要简单,属于原子性的方法或者服务,能够充分复用。然后是这一层只做本领域的业务,保证事物的强一致性,做到高内聚、低耦合。

4、facade层做业务归集,它负责与其他系统做交互,还有数据转换。数据转换也是一个很纠结的地方,如果你要写在分层的代码中,将有大量的get()、set()方法,当然你也可以使用BeanCopy(),前提是你定义的属性名要DO一致。使用BeanCopy,有个很大的缺点,这样会不知道出参是在哪里赋值的,排查问题就有点困难了。

5、特别说明一下,我们的系统入参层次对象应该是由VO到DO,或者DTO 到DO。出去就是由DO到DTO,或者DO到VO。在我之前的项目中,会在DO中定义多个静态方法,用作将DTO或VO转为DO,DO转为DTO或VO。这样这个DO就是一个充血的bean,但是如果业务复杂实体比较多的话,DO就会有太多这样的方法。这就需要自己去权衡了。

6、对于增删查,可以把service方法写的很通用,利用mybatis的动态sql可以有很好的扩展。但是对于修改,如果所有修改的操作都是一个update方法的话,容易出现传递不同的条件而发生不想要的修改的情况。所以会有多个修改方法。这样同样会带来其他问题,后面说到缓存设计再详细说。

7、分包和建类要按DO来。做这个项目最大的两个坑,一个就是各自写各自的代码,完全没有服务化的思想,这个后来改过来了。另外一个就是分包了,这个坑还在,已经是积重难返了。我们现在分包和建service类是按功能分的,比如所有的查询放在Query类中,所有的编辑放在manager类中,这就造成本来该属于一个DO的业务割裂在不同的类中。

8、前面说了Dao操作的对象是DO,但是对于查询来说,我们又不会完全按照DO的属性去做查询,我们希望可以通过一个类知道这个DO的查询条件来筛选数据,这就需要根据每个表来建一个Query类,这个类原则上不应该有id、idList类似含义重复的属性,但是可以提供一个setId()方法。

9、当一个表有很多字段时,比如我们的商品表有100多个字段。我们每次查询不应该带出来所有字段,这就需要对字段进行分级,根据不同级别提供多个查询方法。因为还存在表关联的情况,还要提供是否级联子表的参数,这样一组合查询的方法就多了,所以设计查询的时候,也要想清楚。

© 著作权归作者所有

潜化
粉丝 6
博文 46
码字总数 31901
作品 0
长宁
程序员
私信 提问
#技术分享# SOA 个人一点愚见

自去年加入新的公司到现在整一年了,职涯过程有些迂回,但总体实在曲折中攀升,首先谈谈我所参与公司的产品,该产品定位于SOA架构(SOA这玩意其实不是很新鲜的事物,大体上对其有一定的认知)...

边缘行者
2013/12/18
805
1
#legoo内核# 准则四:使用配置提高杠杆效应

现在的计算机发展可谓是一日千里,特别是我在工作中,总是抢计算机的工作,无法让计算机加倍努力工作,让一切都变的自动化,例如在 程序的持续集成方面,至少我还用认为干预的模式,目前有很...

边缘行者
2014/01/19
70
2
从运维角度看大中型网站架构的演变之路

网上有很多文章类似于我今天要分享的内容,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我将从运维角度全面讲解。 一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩...

李振良
2017/08/09
0
0
从运维角度看中大型网站架构的演变之路

本文出自 “李振良的技术博客” 博客,请务必保留此出处http://lizhenliang.blog.51cto.com/7876557/1951651 前言 网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有...

红尘世间
2017/08/11
0
0
从运维角度看中大型网站架构的演变之路

前言 网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解。 一个成熟的网站架构并不是一开始设计就具备高可用、...

李振良OK
2017/07/28
0
0

没有更多内容

加载失败,请刷新页面

加载更多

golang-字符串-地址分析

demo package mainimport "fmt"func main() {str := "map.baidu.com"fmt.Println(&str, str)str = str[0:5]fmt.Println(&str, str)str = "abc"fmt.Println(&s......

李琼涛
今天
4
0
Spring Boot WebFlux 增删改查完整实战 demo

03:WebFlux Web CRUD 实践 前言 上一篇基于功能性端点去创建一个简单服务,实现了 Hello 。这一篇用 Spring Boot WebFlux 的注解控制层技术创建一个 CRUD WebFlux 应用,让开发更方便。这里...

泥瓦匠BYSocket
今天
6
0
从0开始学FreeRTOS-(列表与列表项)-3

FreeRTOS列表&列表项的源码解读 第一次看列表与列表项的时候,感觉很像是链表,虽然我自己的链表也不太会,但是就是感觉很像。 在FreeRTOS中,列表与列表项使用得非常多,是FreeRTOS的一个数...

杰杰1号
今天
8
0
Java反射

Java 反射 反射是框架设计的灵魂(使用的前提条件:必须先得到代表的字节码的 Class,Class 类 用于表示.class 文件(字节码)) 一、反射的概述 定义:JAVA 反射机制是在运行状态中,对于任...

zzz1122334
今天
5
0
聊聊nacos的LocalConfigInfoProcessor

序 本文主要研究一下nacos的LocalConfigInfoProcessor LocalConfigInfoProcessor nacos-1.1.3/client/src/main/java/com/alibaba/nacos/client/config/impl/LocalConfigInfoProcessor.java p......

go4it
昨天
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部