本文原始碼：GitHub·點這里 || GitEE·點這里

一、分層策略

MVC模式與代碼分層策略，MVC全名是ModelViewController即模型－視圖－控制器，作為一種軟體設計典范，用一種業務邏輯、資料、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶互動的同時，不需要重新撰寫業務邏輯，這是一種開發模式，但并不是實際開發中代碼的分層模式，通常SSM框架的后端代碼分層如下：

• controller控制層：定義服務端介面，入參出參，和一些入參校驗；
• service業務服務層：組裝業務邏輯，業務校驗，構建控制層需要的引數模型；
• dao資料互動層：提供服務層需要的資料查詢方法，處理資料互動條件相關的邏輯；
• mapper持久層：基于mybatis框架需要的原生支持，目前很常用的持久層組件；

二、控制層

1、Rest介面風格

基于資源訪問和處理的邏輯，使用不同風格的注解，例如資源新增，更新，查詢，洗掉，

/**
 * 新增
 */
@PostMapping("/insert")
public Integer insert (@RequestBody BaseInfo baseInfo){
    return baseInfoService.insert(baseInfo);
}
/**
 * 更新
 */
@PutMapping("/update/{id}")
public String update(@PathVariable(value = "https://www.cnblogs.com/cicada-smile/archive/2020/11/09/id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}
/**
 * 主鍵查詢
 */
@GetMapping("/detail/{id}")
public InfoModel detail(@PathVariable(value = "https://www.cnblogs.com/cicada-smile/archive/2020/11/09/id") Integer id) {
    return baseInfoService.detail(id) ;
}
/**
 * 主鍵洗掉
 */
@DeleteMapping("/delete/{id}")
public String delete(@PathVariable(value = "https://www.cnblogs.com/cicada-smile/archive/2020/11/09/id") Integer id) {
    baseInfoService.delete(id) ;
    return "SUS" ;
}

2、介面復用度

不建議介面高度復用，例如增刪改查都各自對接介面即可，基本原則，不同的客戶端端操作，對于獨立的介面，

/**
 * 串列加載
 */
@GetMapping("/list")
public List<BaseInfo> list() {
    return baseInfoService.list(new BaseInfoExample()) ;
}
/**
 * 串列搜索
 */
@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

例如常見的list介面，list通常都有會按條件加載的search機制，而且搜索的判斷條件很復雜，建議分為兩個介面，從實際考慮，大部分場景下都是只使用list介面，很少使用search搜索，

3、入參出參

校驗客戶端必須條件，例如某某條件必填必選等，如果有問題，快速阻斷請求鏈路，做到程式入口控制層攔截回傳，

@PutMapping("/update/{id}")
public String update(@PathVariable(value = "https://www.cnblogs.com/cicada-smile/archive/2020/11/09/id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}

引數在三個以下，可以直接陳列入參，引數在三個或三個以上可以使用物體類統一封裝，

@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

4、引數處理

出參格式處理度基本原則，服務器作為公共資源，避免非必要操作，例如客戶端可自行判斷回傳值是否為空，null等，或者一些常見格式處理，利用客戶端適當分擔服務器壓力，

三、業務服務層

1、業務校驗

例如傳入訂單號，經過資料庫層查詢，沒有訂單資料，這里稱為業務性質的例外，代碼本身沒有問題，但是業務邏輯無法正常執行，

public InfoModel detail(Integer id){
    BaseInfo baseInfo = baseInfoDao.selectByPrimaryKey(id) ;
    if (baseInfo != null){
        DetailInfoEntity detailInfoEntity = detailInfoDao.getById(id);
        if (detailInfoEntity == null){
            LOG.info("id="+id+"資料缺失 DetailInfo");
        }
        return buildModel(baseInfo,detailInfoEntity) ;
    }
    LOG.info("id="+id+"資料完全缺失");
    return null ;
}

2、組裝業務邏輯

通常情況下服務層作為邏輯做復雜的一塊，用來拼接業務核心步驟，可以通過業務邏輯判定，一步一步執行程式，避免在程式入口做大量可能用到的物件創建和需求資料查詢，

public int insert (BaseInfo record){
    record.setCreateTime(new Date());
    int insertFlag = baseInfoDao.insert(record);
    if (insertFlag > 0){
        DetailInfoEntity detailInfoEntity = new DetailInfoEntity();
        detailInfoEntity.setUserId(record.getId());
        detailInfoEntity.setCreateTime(record.getCreateTime());
        if(detailInfoDao.save(detailInfoEntity)){
            return insertFlag ;
        }
    }
    return insertFlag;
}

3、資料模型構建

通常情況業務層是偏復雜的，如果想關快速理解業務層，可以對復雜的業務方法，在提供一個返參構建的方法，用來處理服務層要向控制層回傳的引數，這樣可以讓重度的服務層方法變的清晰，

private InfoModel buildModel (BaseInfo baseInfo,DetailInfoEntity detailInfo){
    InfoModel infoModel = new InfoModel() ;
    infoModel.setBaseInfo(baseInfo);
    infoModel.setDetailInfoEntity(detailInfo);
    return infoModel ;
}

四、資料互動層

1、逆向工程

這里以使用mybatis框架或者mybatis-plus框架作為參考，如果是mybatis框架，建議逆向工程的模板代碼不做自定義的修改，如果需要自定義方法，在mapper和xml層面再自定義一個擴展檔案，用來存放自定義的方法和SQL邏輯，這樣避免表結構變動大引發的強烈不適，

當然現在大部分都會mybatis-plus作為持久層組件，可以避免上述問題，

2、資料互動

針對業務層的需要，提供相應的資料查詢方法，只處理與資料庫互動的邏輯，避免出現業務邏輯，尤其在分布式架構下，不同服務的資料查詢和組裝，不應該出現在該層，

public interface BaseInfoDao {

    int insert(BaseInfo record);

    List<BaseInfo> selectByExample(BaseInfoExample example);

    int updateByPrimaryKey(BaseInfo record);

    BaseInfo selectByPrimaryKey(Integer id);

    int deleteByPrimaryKey(Integer id);

    BaseInfo getById (Integer id) ;
}

五、源代碼地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：編程體系整理

標籤：其他

上一篇：將Map中對應的key和value賦值到物件中

下一篇：Spring Cloud 純干貨，從入門到實戰