目錄
一、推薦
1.分層規約
二、參考
1.分層異常處理規約
2.分層領域模型規約
下圖中預設上層依賴於下層，箭頭關係表示可直接依賴。如：開放介面層可以依賴於 web 層，也可以直接依賴於 service 層，依此類推：
開放介面層：可直接封裝 service 方法暴露成 rpc 介面；通過 web 封裝成 http 介面；進行閘道器安全控制、流量控制等
終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，js 渲染， jsp 渲染，移動端展示等
web層：主要是對訪問控制進行**，各類基本引數校驗，或者不復用的業務簡單處理等
service層：相對具體的業務邏輯服務層
manager層：通用業務處理層，它有如下特徵：
1） 對第三方平台封裝的層，預處理返回結果及轉化異常資訊；
2） 對 service 層通用能力的下沉，如快取方案、中介軟體通用處理；
3） 與 dao 層互動，對多個 dao 的組合復用。
dao層：資料訪問層，與底層 mysql、oracle、hbase 等進行資料互動。
外部介面或第三方平台：包括其它部門 rpc 開放介面，基礎平台，其它公司的 http 介面。
在 dao 層，產生的異常型別有很多，無法用細粒度的異常進行 catch，使用 catch(exception e)方式，並 throw new daoexception(e)，不需要列印日誌，因為日誌在 manager/service 層一定需要捕獲並列印到日誌檔案中去，如果同台伺服器再打日誌，浪費效能和儲存。
在 service 層出現異常時，必須記錄出錯日誌到磁碟，盡可能 帶上引數資訊，相當於保護案發現場。
如果 manager 層與 service 同機部署，日誌方式與 dao 層處理一致，如果是單獨部署，則採用與 service 一致的處理方式。
web 層絕不應該繼續往上拋異常，因為已經處於頂層，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，加上使用者容易理解的錯誤提示資訊。
開放介面層要將異常處理成錯誤碼和錯誤資訊方式返回。
do（data object）：此物件與資料庫表結構一一對應，通過 dao 層向上傳輸資料源物件
dto（data transfer object）：資料傳輸物件，service 或 manager 向外傳輸的物件
bo（business object）：業務物件，由 service 層輸出的封裝業務邏輯的物件
vo（view object）：顯示層物件，通常是 web 向模板渲染引擎層傳輸的物件
query：資料查詢物件，各層接收上層的查詢請求。注意超過 2 個引數的查詢封裝，禁止使用 map 類來傳輸
規約先行 （十八）應用分層
推薦 圖中預設上層依賴於下層，箭頭關係表示可直接依賴，如 開放介面層可以依賴於web 層，也可以直接依賴於 service 層，依此類推 dao 層 資料訪問層，與底層 mysql oracle hbase 等進行資料互動。外部介面或第三方平台 包括其它部門 rpc 開放介面，基礎平台，其它公司的 ...
編碼規約之索引規約
目錄 一 強制 1.業務上具有唯一特性的字段，即使是多個欄位的組合，也必須建成唯一索引 2.超過三個表禁止 join 3.在 varchar 欄位上建立索引時注意項 4.頁面搜尋嚴禁左模糊或者全模糊 二 推薦 1.如果有 order by 的場景注意索引的有序性 2.利用覆蓋索引來進行查詢操作，避免...
Java開發手冊之工程規約（一） 應用分層
1.推薦 圖中預設上層依賴於下層，箭頭關係表示可直接依賴，如 開放介面層可以依賴於web 層，也可以直接依賴於 service 層，依此類推 開放介面層 可直接封裝 service 介面暴露成 rpc 介面 通過 web 封裝成 http 介面 閘道器控 制層等。終端顯示層 各個端的模板渲染並執行顯...