感觉公司项目的设计还不错,想和大家分享一下,欢迎大家留言指出缺陷和可优化之处。
先来简单介绍下项目的构成情况。
公司使用的是微服务设计,框架采用SSM(Spring+SpringMVC+MyBatis),整个项目拆分成7个微服务项目,项目之间采用dubbo进行接口调用,采用kafka进行非实时通信,采用Redis作为内存锁工具。
每个微项目的构建结构层次大体相同:
不需要页面的项目分为两层:
project-all
|——api
|——core
需要页面的项目分为三个子项目:
project-all
|——api
|——core
|——web
- api项目:对外的接口服务。
- core项目:业务逻辑层,包含:biz层、service层、dao层(注:core层依赖api项目)。
- web项目:页面处理层,包含:controller(注:web层依赖core项目)。
业务层次共分为4层:
- Facade层:负责对接收参数进行合法性校验,以及对请求记录进行内存锁定。
- Biz层:负责主要业务逻辑的整合。
- Service层:负责将请求数据和返回数据进行一些特殊处理。
- Dao层:负责数据的持久化。
请求DTO主要分为2层:
- xxxxReq:api层接收接口传输的最原始dto(注:Req存储在api层)。
- xxxxQuery:用来对xxxxReq进行特殊处理,比如将req接收的时间字段进行格式化等。
响应DTO也分为两层:
- xxxxEntity:数据表直接生成的实体类
- xxxxRes:api层对外接口返回的dto
持久层又分为2层:
- Mapper层:存放mybatis自动生成工具产生的最原始的Model、Mapper和Mapper.xml
- Dao层:存放基于Mapper层扩展的Model、Dao和Dao.xml。Dao继承了Mapper,Dao.xml继承了Mapper.xml
这样的设计很明显的让设计很清晰,尤其是持久层的设计非常便于扩展:Mapper层的文件由于在自动化生成的基础上,完全没有任何的改动,所以当表字段变更的时候,可以直接使用mybatis自动化生成工具覆盖掉之前的Mapper层文件。由于Dao层生成的定制化语句非常少,手动修改的工作量还是很少的。
虽然上面的设计很清晰,但是DTO的设计上存在几个问题:
1.Req和Query存在一个问题:那就是Query和Req的字段是非常近似的,但是Query没有继承Req,这使得在Req增加字段的时候,还得在Query中增加字段,非常麻烦且容易遗漏。
public class BaseQuery implements Serializable{
private static final long serialVersionUID = -435214449318006882L;
private St