淺談 SpringMVC 中各層職責的設計

SpringMVC

SpringMVC應該是目前web開發最經常使用的框架。他的項目結構也相對固定，通常都會有如下幾層。

• controller層
• service層
• mapper接口層
• 實體層
• 可能還有什麼 DTO VO 等層次。

這裏主要講下controller層 和 service層，由於我實際工做中發現，什麼該放在controller層，什麼該放在 service層，彷佛每家公司都有本身的作法。

最近一個項目是這樣安排的

public class DepartmentController {
    @Autowired
    private DepartmentService departmentService;

    /**
     * 刪除部門
     * @param departmentId
     * @return
     */
    @RequestMapping(value = "/department", method= RequestMethod.DELETE)
    public Result delete(String departmentId){
        return departmentService.delete(departmentId);
    }
}


public class DepartmentService {
    @Autowired
    private DepartmentMapper departmentMapper;
    @Autowired
    private UserService userService;

    /**
     * 刪除部門
     * @param departmentId
     * @return
     */
    @RequestMapping(value = "department", method= RequestMethod.DELETE)
    public Result delete(String departmentId){
        if(departmentId == null || "".equals(departmentId)){
            return new FailResult("部門id不合法")；
        }
        //刪除部門前，查看部門下是否存在人員
        Result result =  userService.getUserList(departmentId);
        //拆解result 找出結果
        List<User> List = result.getDate();
        if(if list != null && list.size > 0){
            return new FailResult("部門下是否存在人員")；
        }
        int i =  departmentService.delete(departmentId);
        if(i == 1){
            return new SuccessResult<Boolean>(true);
        }
        return new FailResult("刪除失敗")；
    }
}
複製代碼

上面代碼中，Controller層的任務很是簡單，接收前端的參數而後傳給service，service處理完後返回最終結果，至於 參數傳沒穿，格式對不對，甚至最後返回結果的封裝，都放到service中去處理。
咱們能夠看到service的任務很是集中，很是重，而Controller的任務很是輕，就只作了一個轉發的操做。其實這樣分配很是不合理，特別是 最終返回結果的封裝，很是不該該放在service裏面。
上面代碼中咱們想刪除一個部門，先要判斷部門下是否存在人員，因而咱們調用人員的service，結果他返回的是給前端展現的對象，因而咱們不得不，拆解對象，取出咱們想要的結果，很是麻煩。若是他把Result的封裝放在Controller層就很是方便了，service層能夠直接返回處理結果。

通過此次項目後，我一直在思考，Controller層和service層的職責應該怎樣設計纔好。下面說下個人見解。

Controller層

Controller層是前端直接接觸的層，離用戶最近，同時也表明着一個接口。
他的任務應該是你按照個人要求傳遞規定的參數，而且參數的值也合法的話，我就返回給你想要的結果。
從上面分析能夠看出Controller層關注點在兩個方面，請求參數，和響應結果。

所以，controller層的任務是

• 在調用業務層(Serivce)以前，保證業務所須要的參數的個數和內容都要合法。換句話說，在調用service以前，service要求的每一個參數都要有，而且在內容上要合法，而不要把這些操做延遲都service中去作。
  這樣設計的理由也很簡單，你參數都不對，還有必要進入業務層去執行嗎？
• 不要讓業務層(Serivce)返回最終結果(前端須要的結果)。這個也很好理解
  • mapper層應該返回查詢數據庫的結果。
  • service層應該返回業務結果
  • controller層應該根據業務層的返回結果作判斷，而後封裝成前端須要的最終結果

因此Controller層的職責總結起來就兩點。

• 在調用業務方法以前，保證業務方法所需參數的合法性
• 接收業務方法的返回值，根據返回值作判斷，而後封裝成前端須要的最終結果

Service層

service層負責的是業務的處理，它的關注的是業務，不該該作與業務沒有直接關係的事情。 好比：

• 檢查業務參數的合法性。乍一看好像跟業務相關，但咱們換一個角度思考，業務參數不合法就沒有必要進入到業務方法裏面來，再說業務參數是Controller層傳遞過來的，你把不合法的參數傳遞進來是想幹什麼。
• 業務層只返回業務結果，不返回最終結果。這點很容易理解，應爲業務結果不必定就是最終結果，業務層只要負責好本身的業務就行了，至於最終結果，固然是由接口(Controller)層去返回。

這樣設計的緣由是但願各層職責分明，每層負責本身的事，這樣作還有一個好處，那就是，不會存在某層很是 「重」，而某層又很是 「輕」 的狀況。