如何规划一个合理的JAVA项目工程结构
由于阿里Java开发手册对于工程结构的描述仅限于1、2节简单的概述,不能满足多样的实际需求,本文根据多个项目中工程的实践,分享一种较为合理实用的工程结构。
工程结构的原则
有依据、实用。有依据的含义是指做任何操作都是有理论支持的,而不是完全凭个人喜好,也不是完全效仿大厂行为,因为大厂的业务场景不一定适合自己。比如我们组负责的子系统的特点通常没有复杂的业务逻辑,交互的团队也相对较少。此外,有依据也是说服同事认可该结构的手段之一,毕竟工程结构是大家协作开发的基础。实用的含义是指该结构在真正编程的时候是否方便,比如来来回回copy bean,这就表示需要简化bean的种类了。笔者一直相信好的结构绝不是一蹴而就的,而是有了大的指引方向同时结合自己的项目特点不断地演化而来的。
工程结构的具体内容
2.1 工程结构分层
工程一共分4层,结构图如下
Controller层、Service层、Manager层、Dao层共4层。一个请求从Controller层到Dao层,按照箭头的方向依次向下调用,然后原路返回。
Controller层:控制层。现在很多项目都是前后端分离,前后端使用json数据直接交互,该层承担的功能较少;
Service层:业务逻辑层,每个接口自己的特殊逻辑放在这一层;
Manager层:业务逻辑通用层,每个数据库表可以共用的部分,比如常见的增删改查;
Dao层:数据访问层,根据数据源使用的不同,在具体使用的时调整为具体的方式。
2.2、Bean的种类
根据实际经验建议,设置3种即可。分别是DTO、PO、Param即可。
DTO : 数据传输对象。用在请求即将返回的时候。在Service层使用,在Service层完成PO向DTO的转换。也就是从数据库把数据查询出后,转换为请求需要的数据格式和字段。
PO : 持久化对象。与数据源中存储的表字段一一对应。在Manager层、Dao层使用。根据Param查询出对应的PO对象。
Param : 查询参数对象。一个查询接口对应一个查询对象。在Controller层、Service层、Manager层使用。如果接口的定制性极强,无法复用使用Manager层提供的通用的增、删、改、查方法,Param最终会进入到底层,直接进行在Dao层查询,但是这种情况较少。
2.3 各层的作用及理由
Controller层:
该层应该放哪些内容呢?
1、各类基本参数校验
原因:不放到Service层的原因,可以共用的校验的业务数量很少。以常见的分页和导出为例,这2个功能经常组合出现,可是在处理参数校验的时候可以共用的也并非全部。参数放在此层的另外一个好处是有错误会以最短路径返回。
public class AController {
@GetMapping("/a/list")
public ResponseBaseDTO<ResponseListDTO> list(@RequestBody RequestDTO requestDTO){
BasicValidator.validateEmpty(requestDTO.getSchoolId(),"schoolId");
return null;
}
}
2、组装最终的返回对象
各个接口的返回,比如列表查询、单值查询,需要返回相同格式的数据。处理的位置是在Controller层。在Controller层返回,属于数据渲染处理,比较合适。同时不与Service的业务处理耦合,让其处理看起来比较单一和清爽。
public class AController {
@Autowired
private AService aService;
@GetMapping("/a/list")
public ResponseBaseDTO<ResponseListDTO> list(@RequestBody RequestParam requestParam){
BasicValidator.validateEmpty(requestParam.getSchoolId(),"schoolId");
List items = aService.list(requestParam);
ResponseBaseDTO<ResponseListDTO<String>> base = new ResponseBaseDTO<>();
base.setData(new ResponseListDTO<>(items));
return base;
}
}
对于相同类型的数据返回,统一格式。格式如下。
列表返回
{
"status": "1",
"msg": "OK",
"data": {
"items": [
{}
]
}
}
Service层:
该层应该放哪些内容呢?
1、定制化接口,定制化逻辑,不考虑复用
不考虑复用指的是不会被2个及2个以上的Controller调用。在一段工程中,总有一个代码块是独一无二的,不与其他人共用,具有自己特殊的逻辑,而这个位置就在Service层。因为共用的代码位置下沉到了Manager层。类之间相互交互是Service直接调用另外一个类的Manager
@Service
public class AServiceImpl implements AService {
@Resource
private AManager aManager;
@Resource
private BManager bManager;
}
2、如果需要控制事务,在此层控制事务
尽可能减少事务嵌套。事务嵌套需要处理事务的传播行为,所以将事务的控制放到不共用的位置,对于事务的处理较为简单,减少出错的可能性。
3、多个查询对象Param满足多样需求
数据对象 PO,对象的字段与数据库表字段一一对应,Param对象可以理解为PO对象的查询封装,从理论上讲Param是PO各个字段的排列组合情况,意思就是对于字符串类型字段,会有等于查询(=)、模糊查询(like)、列表查询(in)等,很多样,实际上真正使用的时候并不会使用到每一种情况,此时一般是需要一个添加一个。举个例子:
代码块
public class PatrolTaskStatusGroupByParam {
private String typeCode;
private Integer schoolId;
}
public class PatrolTaskStatusRefreshParam extends LoginInfoParam {
private String typeCode;
private Set<String> classCodes;
}
这些Param产生的原则是1个接口对应1个Param,至少我们从前端接收参数的时候要1次性接收完毕,拿到Param后在内部涉及多个对象的新增或者修改时,将Param转换为相应的PO,该转化在Service层完成。在Service层调用不同Manager,完成聚合。针对同一个PO对象产生的多个Param对象,每个Param各异,要求返回的对象基本也没有共通性,所以Service层就是定制化模块。
Manager层
该层应该放哪些内容呢?
1、通用功能
典型的增删改查操作;一般借助现有的框架即可,比如mybatis plus
2、该对象复用极高的方法
举例,对于学校对象的查询,当学校ID等于项目中心时,需要返回所有的分校,类似方法复用性极高,需要放入Manager层.
其他对象的Service在调用该对象的方法时,应该调Manager,而不是调Service。因为在Service写的是无法通用的方法,而Manager写的才是通用的方法。
3、调用外围系统方法放在该层
外围系统对于当前系统提供的功能一般不属于定制化功能,而是通用性功能。所以不是放在Service层,而是放在Manager层。另外一个好处是方便进行统一管理。调用外部系统一般http方式较多,放在Manager层,相当于统一入口,不会再分散在程序的各处,在统一设置超时时间、身份信息、请求和返回日志时非常方便管理。
比如我们接收到用户的token,验证用户身份时,需要调用外围系统,并接收外围系统的返回结果以让我们知道当前登录人的信息。该类型方法需要在Manager层暴露接口方法。
4、自己封装的调用中间件的方法
对于中间件的使用,也属于通用性极强的功能。所以不是放在Service层,而是放在Manager层。另外一个好处,和上面的第3条类似,统一入口,方便统一管理。以Redis中常用的get、set为例,对其进行任何操作,都没有必要让上游业务系统感知到。尤其是当出现中间件版本升级等问题时,统一封装,所以代码改动量极小,大大提升工作效率。
Dao层
该层应该放哪些内容呢?
1、数据库操作相关
距离数据源最近,只能处理与数据源相关问题。没有业务逻辑。
当数据源是mysql时,该层一般会借助mybatis框架,编写sql语句,查询表的相关数据,并返回数据供调用方展示;
public interface IUserMapper extends BaseMapper<UserPO> {
}
当数据源是elastic search时,该层借助elastic client 编写dsl语句,查询索引的相关数据,并返回数据供上游方法使用。
@Autowired
private RestHighLevelClient restHighLevelClient;
public List<Map<String, Object>> searchMap(String index, BoolQueryBuilder bool_query, Integer from, Integer size, String[] includes, String[] excludes, SortBuilder... sort_builders) {
SearchSourceBuilder source_builder = sourceBuilder(from, size, includes, excludes);
source_builder.query(bool_query);
SearchRequest search_request = new SearchRequest(index);
search_request.source(source_builder);
SearchResponse response = restHighLevelClient.search(search_request, RequestOptions.DEFAULT);
List<Map<String, Object>> res = new ArrayList(response.getHits().getHits().length);
for (SearchHit hit : response.getHits()) {
Map<String, Object> source_map = hit.getSourceAsMap();
res.add(source_map);
}
return res;
}
小结
本文核心意图是明确JAVA工程每层所放置的内容。大家在开发的过程中,总是有这样的感觉,放这里合适,放那里也合适的困惑。工程结构属于一种规范,没有最好,只有最合适,希望这篇文章对你在日后的开发过程中有帮助。