java服务端研发知识图谱（我们见过的Java服务端乱象）

java服务端研发知识图谱（我们见过的Java服务端乱象）/** 基础服务类 */ public class BaseService { /** 注入DAO相关 */ /** 用户DAO */ @Autowired protected UserDAO userDAO; ... /** 注入服务相关 */ /** 短信服务 */ @Autowired protected SmsService smsService; ... /** 注入参数相关 */ /** 系统名称 */ @Value("${example.systemName}") protected String systemName; ... /** 静态常量相关 */ /** 超级用户标识 */ protected static final long SUPPER_USER_ID = 0L; ... /** 服务函数相关 */ /** 获取用

导读

查尔斯·狄更斯在《双城记》中写道：“这是一个最好的时代，也是一个最坏的时代。”移动互联网的快速发展，出现了许多新机遇，很多创业者伺机而动；随着行业竞争加剧，互联网红利逐渐消失，很多创业公司九死一生。

笔者在初创公司摸爬滚打数年，接触了各式各样的Java微服务架构，从中获得了一些优秀的理念，但也发现了一些不合理的现象。现在，笔者总结了一些创业公司存在的Java服务端乱象，并尝试性地给出了一些不成熟的建议。

1.使用Controller基类和Service基类

1.1.现象描述

1.1.1.Controller基类

常见的Controller基类如下：

/** 基础控制器类 */ public class BaseController { /** 注入服务相关 */ /** 用户服务 */ @Autowired protected UserService userService; ... /** 静态常量相关 */ /** 手机号模式 */ protected static final String PHONE_PATTERN = "/^[1]([3-9])[0-9]{9}$/"; ... /** 静态函数相关 */ /** 验证电话 */ protected static vaildPhone(String phone) {...} ... }

常见的Controller基类主要包含注入服务、静态常量和静态函数等，便于所有的Controller继承它，并在函数中可以直接使用这些资源。

1.1.2.Service基类

常见的Service基类如下：

/** 基础服务类 */ public class BaseService { /** 注入DAO相关 */ /** 用户DAO */ @Autowired protected UserDAO userDAO; ... /** 注入服务相关 */ /** 短信服务 */ @Autowired protected SmsService smsService; ... /** 注入参数相关 */ /** 系统名称 */ @Value("${example.systemName}") protected String systemName; ... /** 静态常量相关 */ /** 超级用户标识 */ protected static final long SUPPER_USER_ID = 0L; ... /** 服务函数相关 */ /** 获取用户函数 */ protected UserDO getUser(Long userId) {...} ... /** 静态函数相关 */ /** 获取用户名称 */ protected static String getUserName(UserDO user) {...} ... }

常见的Service基类主要包括注入DAO、注入服务、注入参数、静态常量、服务函数、静态函数等，便于所有的Service继承它，并在函数中可以直接使用这些资源。

1.2.论证基类必要性

表现层（Presentation）：又称控制层（Controller），负责接收客户端请求，并向客户端响应结果，通常采用HTTP协议。

业务层（Business）：又称服务层（Service），负责业务相关逻辑处理，按照功能分为服务、作业等。

持久层（Persistence）：又称仓库层（Repository），负责数据的持久化，用于业务层访问缓存和数据库。

所以，把业务代码写入到Controller类中，是不符合SpringMVC服务端三层架构规范的。

3.把持久层代码写在Service中

把持久层代码写在Service中，从功能上来看并没有什么问题，这也是很多人欣然接受的原因。

3.1.引起以下主要问题

1. 业务层和持久层混杂在一起，不符合SpringMVC服务端三层架构规范；
2. 在业务逻辑中组装语句、主键等，增加了业务逻辑的复杂度；
3. 在业务逻辑中直接使用第三方中间件，不便于第三方持久化中间件的替换；
4. 同一对象的持久层代码分散在各个业务逻辑中，背离了面对对象的编程思想；
5. 在写单元测试用例时，无法对持久层接口函数直接测试。

3.2.把数据库代码写在Service中

这里以数据库持久化中间件Hibernate的直接查询为例。

现象描述：

/** 用户服务类 */ @Service public class UserService { /** 会话工厂 */ @Autowired private SessionFactory sessionFactory; /** 根据工号获取用户函数 */ public UserVO getUserByEmpId(String empId) { // 组装HQL语句 String hql = "from t_user where emp_id = '" empId "'"; // 执行数据库查询 Query query = sessionFactory.getCurrentSession().createQuery(hql); List<UserDO> userList = query.list(); if (CollectionUtils.isEmpty(userList)) { return null; } // 转化并返回用户 UserVO userVO = new UserVO(); BeanUtils.copyProperties(userList.get(0) userVO); return userVO; } }

建议方案：

/** 用户DAO类 */ @Repository public class UserDAO { /** 会话工厂 */ @Autowired private SessionFactory sessionFactory; /** 根据工号获取用户函数 */ public UserDO getUserByEmpId(String empId) { // 组装HQL语句 String hql = "from t_user where emp_id = '" empId "'"; // 执行数据库查询 Query query = sessionFactory.getCurrentSession().createQuery(hql); List<UserDO> userList = query.list(); if (CollectionUtils.isEmpty(userList)) { return null; } // 返回用户信息 return userList.get(0); } } /** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** 根据工号获取用户函数 */ public UserVO getUserByEmpId(String empId) { // 根据工号查询用户 UserDO userDO = userDAO.getUserByEmpId(empId); if (Objects.isNull(userDO)) { return null; } // 转化并返回用户 UserVO userVO = new UserVO(); BeanUtils.copyProperties(userDO userVO); return userVO; } }

关于插件：

阿里的AliGenerator是一款基于MyBatis Generator改造的DAO层代码自动生成工具。利用AliGenerator生成的代码，在执行复杂查询的时候，需要在业务代码中组装查询条件，使业务代码显得特别臃肿。

/** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** 获取用户函数 */ public UserVO getUser(String companyId String empId) { // 查询数据库 UserParam userParam = new UserParam(); userParam.createCriteria().andCompanyIdEqualTo(companyId) .andEmpIdEqualTo(empId) .andStatusEqualTo(UserStatus.ENABLE.getValue()); List<UserDO> userList = userDAO.selectByParam(userParam); if (CollectionUtils.isEmpty(userList)) { return null; } // 转化并返回用户 UserVO userVO = new UserVO(); BeanUtils.copyProperties(userList.get(0) userVO); return userVO; } }

个人不喜欢用DAO层代码生成插件，更喜欢用原汁原味的MyBatis XML映射，主要原因如下：

• 会在项目中导入一些不符合规范的代码；
• 只需要进行一个简单查询，也需要导入一整套复杂代码；
• 进行复杂查询时，拼装条件的代码复杂且不直观，不如在XML中直接编写SQL语句；
• 变更表格后需要重新生成代码并进行覆盖，可能会不小心删除自定义函数。

当然，既然选择了使用DAO层代码生成插件，在享受便利的同时也应该接受插件的缺点。

3.3.把Redis代码写在Service中

现象描述：

/** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** Redis模板 */ @Autowired private RedisTemplate<String String> redisTemplate; /** 用户主键模式 */ private static final String USER_KEY_PATTERN = "hash::user::%s"; /** 保存用户函数 */ public void saveUser(UserVO user) { // 转化用户信息 UserDO userDO = transUser(user); // 保存Redis用户 String userKey = MessageFormat.format(USER_KEY_PATTERN userDO.getId()); Map<String String> fieldMap = new HashMap<>(8); fieldMap.put(UserDO.CONST_NAME user.getName()); fieldMap.put(UserDO.CONST_SEX String.valueOf(user.getSex())); fieldMap.put(UserDO.CONST_AGE String.valueOf(user.getAge())); redisTemplate.opsForHash().putAll(userKey fieldMap); // 保存数据库用户 userDAO.save(userDO); } }

建议方案：

/** 用户Redis类 */ @Repository public class UserRedis { /** Redis模板 */ @Autowired private RedisTemplate<String String> redisTemplate; /** 主键模式 */ private static final String KEY_PATTERN = "hash::user::%s"; /** 保存用户函数 */ public UserDO save(UserDO user) { String key = MessageFormat.format(KEY_PATTERN userDO.getId()); Map<String String> fieldMap = new HashMap<>(8); fieldMap.put(UserDO.CONST_NAME user.getName()); fieldMap.put(UserDO.CONST_SEX String.valueOf(user.getSex())); fieldMap.put(UserDO.CONST_AGE String.valueOf(user.getAge())); redisTemplate.opsForHash().putAll(key fieldMap); } } /** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** 用户Redis */ @Autowired private UserRedis userRedis; /** 保存用户函数 */ public void saveUser(UserVO user) { // 转化用户信息 UserDO userDO = transUser(user); // 保存Redis用户 userRedis.save(userDO); // 保存数据库用户 userDAO.save(userDO); } }

把一个Redis对象相关操作接口封装为一个DAO类，符合面对对象的编程思想，也符合SpringMVC服务端三层架构规范，更便于代码的管理和维护。

4.把数据库模型类暴露给接口

4.1.现象描述

/** 用户DAO类 */ @Repository public class UserDAO { /** 获取用户函数 */ public UserDO getUser(Long userId) {...} } /** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** 获取用户函数 */ public UserDO getUser(Long userId) { return userDAO.getUser(userId); } } /** 用户控制器类 */ @Controller @RequestMapping("/user") public class UserController { /** 用户服务 */ @Autowired private UserService userService; /** 获取用户函数 */ @RequestMapping(path = "/getUser" method = RequestMethod.GET) public Result<UserDO> getUser(@RequestParam(name = "userId" required = true) Long userId) { UserDO user = userService.getUser(userId); return Result.success(user); } }

上面的代码，看上去是满足SpringMVC服务端三层架构的，唯一的问题就是把数据库模型类UserDO直接暴露给了外部接口。

4.2.存在问题及解决方案

存在问题：

1. 间接暴露数据库表格设计，给竞争对手竞品分析带来方便；
2. 如果数据库查询不做字段限制，会导致接口数据庞大，浪费用户的宝贵流量；
3. 如果数据库查询不做字段限制，容易把敏感字段暴露给接口，导致出现数据的安全问题；
4. 如果数据库模型类不能满足接口需求，需要在数据库模型类中添加别的字段，导致数据库模型类跟数据库字段不匹配问题；
5. 如果没有维护好接口文档，通过阅读代码是无法分辨出数据库模型类中哪些字段是接口使用的，导致代码的可维护性变差。

解决方案：

1. 从管理制度上要求数据库和接口的模型类完全独立；
2. 从项目结构上限制开发人员把数据库模型类暴露给接口。

4.3.项目搭建的三种方式

下面，将介绍如何更科学地搭建Java项目，有效地限制开发人员把数据库模型类暴露给接口。

第1种：共用模型的项目搭建

共用模型的项目搭建，把所有模型类放在一个模型项目（example-model）中，其它项目（example-repository、example-service、example-website）都依赖该模型项目，关系图如下：

风险：

表现层项目（example-webapp）可以调用业务层项目（example-service）中的任意服务函数，甚至于越过业务层直接调用持久层项目（example-repository）的DAO函数。

第2种：模型分离的项目搭建

模型分离的项目搭建，单独搭建API项目（example-api），抽象出对外接口及其模型VO类。业务层项目（example-service）实现了这些接口，并向表现层项目（example-webapp）提供服务。表现层项目（example-webapp）只调用API项目（example-api）定义的服务接口。

风险：

表现层项目（example-webapp）仍然可以调用业务层项目（example-service）提供的内部服务函数和持久层项目（example-repository）的DAO函数。为了避免这种情况，只好管理制度上要求表现层项目（example-webapp）只能调用API项目（example-api）定义的服务接口函数。

第3种：服务化的项目搭建

服务化的项目搭，就是把业务层项目（example-service）和持久层项目（example-repository）通过Dubbo项目（example-dubbo）打包成一个服务，向业务层项目（example-webapp）或其它业务项目（other-service）提供API项目（example-api）中定义的接口函数。

说明：Dubbo项目（example-dubbo）只发布API项目（example-api）中定义的服务接口，保证了数据库模型无法暴露。业务层项目（example-webapp）或其它业务项目（other-service）只依赖了API项目（example-api），只能调用该项目中定义的服务接口。

4.4.一条不太建议的建议

有人会问：接口模型和持久层模型分离，接口定义了一个查询数据模型VO类，持久层也需要定义一个查询数据模型DO类；接口定义了一个返回数据模型VO类，持久层也需要定义一个返回数据模型DO类……这样，对于项目早期快速迭代开发非常不利。能不能只让接口不暴露持久层数据模型，而能够让持久层使用接口的数据模型？

如果从SpringMVC服务端三层架构来说，这是不允许的，因为它会影响三层架构的独立性。但是，如果从快速迭代开发来说，这是允许的，因为它并不会暴露数据库模型类。所以，这是一条不太建议的建议。

/** 用户DAO类 */ @Repository public class UserDAO { /** 统计用户函数 */ public Long countByParameter(QueryUserParameterVO parameter) {...} /** 查询用户函数 */ public List<UserVO> queryByParameter(QueryUserParameterVO parameter) {...} } /** 用户服务类 */ @Service public class UserService { /** 用户DAO */ @Autowired private UserDAO userDAO; /** 查询用户函数 */ public PageData<UserVO> queryUser(QueryUserParameterVO parameter) { Long totalCount = userDAO.countByParameter(parameter); List<UserVO> userList = null; if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) { userList = userDAO.queryByParameter(parameter); } return new PageData<>(totalCount userList); } } /** 用户控制器类 */ @Controller @RequestMapping("/user") public class UserController { /** 用户服务 */ @Autowired private UserService userService; /** 查询用户函数(parameter中包括分页参数startIndex和pageSize) */ @RequestMapping(path = "/queryUser" method = RequestMethod.POST) public Result<PageData<UserVO>> queryUser(@Valid @RequestBody QueryUserParameterVO parameter) { PageData<UserVO> pageData = userService.queryUser(parameter); return Result.success(pageData); } } 后记

“仁者见仁、智者见智”，每个人都有自己的想法，而文章的内容也只是我的一家之言。

谨以此文献给那些我工作过的创业公司，是您们曾经放手让我去整改乱象，让我从中受益颇深并得以技术成长。

作者：中间件小哥