一、分層政策
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 = "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 = "id") Integer id) {
return baseInfoService.detail(id) ;
}
/**
* 主鍵删除
*/
@DeleteMapping("/delete/{id}")
public String delete(@PathVariable(value = "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 = "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