查爾斯·狄更斯在《雙城記》中寫道：“這是一個最好的時代，也是一個最壞的時代。”
移動網際網路的快速發展，出現了許多新機遇，很多創業者伺機而動；随着行業競争加劇，網際網路紅利逐漸消失，很多創業公司九死一生。筆者在初創公司摸爬滾打數年，接觸了各式各樣的 Java 微服務架構，從中獲得了一些優秀的理念，但也發現了一些不合理的現象。現在，筆者總結了一些創業公司存在的 Java 服務端亂象，并嘗試性地給出了一些不成熟的建議。
使用Controller基類和Service基類
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 繼承它，并在函數中可以直接使用這些資源。
- Service 基類
常見的 Service 基類如下：
/** 基礎服務類 */
public class BaseService {
/** 注入DAO相關 */
/** 使用者DAO */
protected UserDAO userDAO;
/** 注入服務相關 */
/** 短信服務 */
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 繼承它，并在函數中可以直接使用這些資源。
2、論證基類必要性
首先，了解一下裡氏替換原則：
裡氏代換原則（Liskov Substitution Principle，簡稱LSP）：所有引用基類（父類）的地方必須能透明地使用其子類的對象。
其次，了解一下基類的優點：
- 子類擁有父類的所有方法和屬性，進而減少了建立子類的工作量；
- 提高了代碼的重用性，子類擁有父類的所有功能；
- 提高了代碼的擴充性，子類可以添加自己的功能。
是以，我們可以得出以下結論：
- Controller 基類和 Service 基類在整個項目中并沒有直接被使用，也就沒有可使用其子類替換基類的場景，是以不滿足裡氏替換原則；
- Controller 基類和 Service 基類并沒有抽象接口函數或虛函數，即所有繼承基類的子類間沒有相關共性，直接導緻在項目中仍然使用的是子類；
- Controller 基類和 Service 基類隻關注了重用性，即子類能夠輕松使用基類的注入DAO、注入服務、注入參數、靜态常量、服務函數、靜态函數等資源。但是，忽略了這些資源的必要性，即這些資源并不是子類所必須的，反而給子類帶來了加載時的性能損耗。
綜上所述，Controller 基類和 Service 基類隻是一個雜湊類，并不是一個真正意義上的基類，需要進行拆分。
3、拆分基類的方法
由于 Service 基類比 Controller 基類更典型，本文以 Service 基類舉例說明如何來拆分“基類”。
-
把注入執行個體放入實作類
根據“使用即引入、無用則删除”原則，在需要使用的實作類中注入需要使用的DAO、服務和參數。
/** 使用者服務類 */
@ Service
public class UserService {
@ Autowired
private UserDAO userDAO;
private SmsService smsService;
@ Value("${ example .systemName}")
private String systemName;
-
把靜态常量放入常量類
對于靜态常量，可以把它們封裝到對應的常量類中，在需要時直接使用即可。
/** 例子常量類 */
public class ExampleConstants {
public static final long SUPPER_USER_ID = 0L;
-
把服務函數放入服務類
對于服務函數，可以把它們封裝到對應的服務類中。在别的服務類使用時，可以注入該服務類執行個體，然後通過執行個體調用服務函數。
@Service
public class UserService {
public UserDO getUser(Long userId) {...}
}
/** 公司服務類 */
public class CompanyService {
/** 使用者服務 */
private UserService userService;
/** 擷取管理者 */
public UserDO getManager(Long companyId) {
CompanyDO company = ...;
return userService.getUser(company.getManagerId());
}
-
把靜态函數放入工具類
對于靜态函數，可以把它們封裝到對應的工具類中，在需要時直接使用即可。
/** 使用者輔助類 */
public class UserHelper {
public static String getUserName(UserDO user) {...}
把業務代碼寫在 Controller 中
我們會經常會在 Controller 類中看到這樣的代碼：
/** 使用者控制器類 */
@Controller
@RequestMapping("/user")
public class UserController {
@Autowired
private UserDAO userDAO;
@ResponseBody
@RequestMapping(path = "/getUser", method = RequestMethod.GET)
public Result<UserVO> getUser( @RequestParam(name = "userId", required = true) Long userId) {
// 擷取使用者資訊
UserDO userDO = userDAO.getUser(userId);
if (Objects.isNull(userDO)) {
return null;
}
// 拷貝并傳回使用者
UserVO userVO = new UserVO();
BeanUtils.copyProperties(userDO, userVO);
return Result.success(userVO);
編寫人員給出的理由是：一個簡單的接口函數，這麼寫也能滿足需求，沒有必要去封裝成一個服務函數。
2、一個特殊的案例
案例代碼如下：
/** 測試控制器類 */
@RequestMapping("/test")
public class TestController {
@Value("${example.systemName}")
private String systemName;
/** 通路函數 */
@RequestMapping(path = "/access", method = RequestMethod.GET)
public String access() {
return String.format( "系統(%s)歡迎您通路！", systemName);
通路結果如下：
curl http: //localhost:8080/test/access
系統( null)歡迎您通路！
為什麼參數systemName（系統名稱）沒有被注入值？《Spring Documentation》給出的解釋是：
Note that actual processing of the @Value annotation is performed by a BeanPostProcessor.
BeanPostProcessor interfaces are scoped per-container. This is only relevant if you are using container hierarchies. If you define a BeanPostProcessor in one container, it will only do its work on the beans in that container. Beans that are defined in one container are not post-processed by a BeanPostProcessor in another container, even if both containers are part of the same hierarchy.
意思是說：@Value是通過BeanPostProcessor來處理的，而WebApplicationContex和ApplicationContext是單獨處理的，是以WebApplicationContex 不能使用父容器的屬性值。
是以，Controller 不滿足 Service 的需求，不要把業務代碼寫在 Controller 類中。
3、服務端三層架構
SpringMVC 服務端采用經典的三層架構，即表現層、業務層、持久層，分别采用@Controller、@Service、@Repository進行類注解。
表現層（Presentation）：又稱控制層（Controller），負責接收用戶端請求，并向用戶端響應結果，通常采用HTTP協定。
業務層（Business）：又稱服務層（Service），負責業務相關邏輯處理，按照功能分為服務、作業等。
持久層（Persistence）：又稱倉庫層（Repository），負責資料的持久化，用于業務層通路緩存和資料庫。
是以，把業務代碼寫入到Controller類中，是不符合SpringMVC服務端三層架構規範的。
把持久層代碼寫在 Service 中
把持久層代碼寫在 Service 中，從功能上來看并沒有什麼問題，這也是很多人欣然接受的原因。
1、引起以下主要問題
- 業務層和持久層混雜在一起，不符合SpringMVC服務端三層架構規範；
- 在業務邏輯中組裝語句、主鍵等，增加了業務邏輯的複雜度；
- 在業務邏輯中直接使用第三方中間件，不便于第三方持久化中間件的替換；
- 同一對象的持久層代碼分散在各個業務邏輯中，背離了面對對象的程式設計思想；
- 在寫單元測試用例時，無法對持久層接口函數直接測試。
2、把資料庫代碼寫在Service中
這裡以資料庫持久化中間件 Hibernate 的直接查詢為例。
現象描述：
/** 會話工廠 */
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)) {
// 轉化并傳回使用者
UserVO userVO = new UserVO();
BeanUtils.copyProperties(userList. get( 0), userVO);
return userVO;
建議方案：
/** 使用者DAO類 */
@Repository
public class UserDAO {
/** 會話工廠 */
private SessionFactory sessionFactory;
public UserDO getUserByEmpId(String empId) {
String hql = "from t_user where emp_id = '" + empId + "'";
List<UserDO> userList = query.list();
// 傳回使用者資訊
return userList. get( 0);
public class UserService {
public UserVO getUserByEmpId(String empId) {
// 根據工号查詢使用者
UserDO userDO = userDAO.getUserByEmpId(empId);
關于插件：
阿裡的 AliGenerator 是一款基于 MyBatis Generator 改造的 DAO 層代碼自動生成工具。利用 AliGenerator 生成的代碼，在執行複雜查詢的時候，需要在業務代碼中組裝查詢條件，使業務代碼顯得特别臃腫。
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);
個人不喜歡用 DAO 層代碼生成插件，更喜歡用原汁原味的 MyBatis XML 映射，主要原因如下：
- 會在項目中導入一些不符合規範的代碼；
- 隻需要進行一個簡單查詢，也需要導入一整套複雜代碼；
- 進行複雜查詢時，拼裝條件的代碼複雜且不直覺，不如在XML中直接編寫SQL語句；
- 變更表格後需要重新生成代碼并進行覆寫，可能會不小心删除自定義函數。
當然，既然選擇了使用 DAO 層代碼生成插件，在享受便利的同時也應該接受插件的缺點。
3、把 Redis 代碼寫在 Service 中
/** Redis模闆 */
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類 */
public class UserRedis {
/** 主鍵模式 */
private static final String KEY_PATTERN = "hash::user::%s";
public UserDO save(UserDO user) {
String key = MessageFormat.format(KEY_PATTERN, userDO.getId());
redisTemplate.opsForHash().putAll(key, fieldMap);
/** 使用者Redis */
private UserRedis userRedis;
userRedis.save(userDO);
把一個 Redis 對象相關操作接口封裝為一個 DAO 類，符合面對對象的程式設計思想，也符合 SpringMVC 服務端三層架構規範，更便于代碼的管理和維護。
把資料庫模型類暴露給接口
public class UserDAO {
public UserDO getUser( Long userId) {...}
public UserDO getUser( Long userId) {
return userDAO.getUser(userId);
public Result<UserDO> getUser( @RequestParam(name = "userId", required = true) Long userId) {
UserDO user = userService.getUser(userId);
return Result.success(user);
上面的代碼，看上去是滿足 SpringMVC 服務端三層架構的，唯一的問題就是把資料庫模型類 UserDO 直接暴露給了外部接口。
2、存在問題及解決方案
存在問題：
- 間接暴露資料庫表格設計，給競争對手競品分析帶來友善；
- 如果資料庫查詢不做字段限制，會導緻接口資料龐大，浪費使用者的寶貴流量；
- 如果資料庫查詢不做字段限制，容易把敏感字段暴露給接口，導緻出現資料的安全問題；
- 如果資料庫模型類不能滿足接口需求，需要在資料庫模型類中添加别的字段，導緻資料庫模型類跟資料庫字段不比對問題；
- 如果沒有維護好接口文檔，通過閱讀代碼是無法分辨出資料庫模型類中哪些字段是接口使用的，導緻代碼的可維護性變差。
解決方案：
- 從管理制度上要求資料庫和接口的模型類完全獨立；
- 從項目結構上限制開發人員把資料庫模型類暴露給接口。
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、一條不太建議的建議
有人會問：接口模型和持久層模型分離，接口定義了一個查詢資料模型VO類，持久層也需要定義一個查詢資料模型DO類；接口定義了一個傳回資料模型VO類，持久層也需要定義一個傳回資料模型DO類……這樣，對于項目早期快速疊代開發非常不利。能不能隻讓接口不暴露持久層資料模型，而能夠讓持久層使用接口的資料模型？
如果從SpringMVC服務端三層架構來說，這是不允許的，因為它會影響三層架構的獨立性。但是，如果從快速疊代開發來說，這是允許的，因為它并不會暴露資料庫模型類。是以，這是一條不太建議的建議。
/** 統計使用者函數 */
public Long countByParameter(QueryUserParameterVO parameter) {...}
/** 查詢使用者函數 */
public List<UserVO> queryByParameter(QueryUserParameterVO parameter) {...}
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);
/** 查詢使用者函數(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);
“仁者見仁、智者見智”，每個人都有自己的想法，而文章的内容也隻是我的一家之言。
謹以此文獻給那些我工作過的創業公司，是您們曾經放手讓我去整改亂象，讓我從中受益頗深并得以技術成長。
作者簡介：陳昌毅，花名常意，高德地圖技術專家，2018年加入阿裡巴巴，一直從事地圖資料采集的相關工作。
如果喜歡本篇文章，歡迎 轉發、點贊 。關注訂閱号「Web項目聚集地」，回複「全棧」即可擷取 2019 年最新 Java、Python、前端學習視訊資源。
喜歡文章，點個在看 ↓