1.推薦：圖 6-1 中預設上層依賴於下層，箭頭關係表示可直接依賴，如：開發介面層可以依賴於 web 層，也可以直接依賴於 service 層，以此類推。
圖 6-1 層級依賴關係
）開放介面層：可直接封裝 service 方法暴露成 rpc 介面：通過 web 封裝成 http 介面：進行閘道器安全控制、流量控制等。
）終端顯示層：各個短的模組渲染並執行顯示的層。當前只要是 velocity 渲染、jsp 渲染、移動端展示等。
）web 層：主要是對訪問控制進行**，對各類基本引數校驗，或者對不符用的業務簡單處理等。
）service 層：相對具體的業務邏輯服務層。
）manager 層：通用業務處理層，它有如下特徵。
。對第三方平台封裝的層，預處理返回結果及轉化異常資訊；
。對 service 層通用能力的下沉，如快取方案、中介軟體通用處理。
。與 dao 層互動，對多個 dao 的組合復用。
）dao 層：資料訪問層，與的層 mysql 、orcle 、hbase 等進行資料互動。
）外部藉口或第三方平台：包括其他部門 rpc 開放介面，基礎平台，其他公司的 http 介面。
2.參考：（封層異常處理規約）在 dao 層，產生的異常型別有很多，無法用細粒度的異常進行 catch ，使用
catch (exception e) 的方式，並 throw new daoexception(e)。不需要列印日誌，因為日誌在 manager / service 層，一定需要捕獲並寫道日誌檔案中去。如果同台伺服器再寫日誌，會浪費效能和儲存。在 service 層出現異常時，必須將出錯日誌記錄到磁碟，盡可能帶上引數資訊，相當於保護案發現場。如果 manager 層與 service 層同機部署，則日誌方式與 dao 層一致；如果是單獨部署，則採用與 service 一致的處理方式。web 層決不應該繼續往上拋異常，因為已經處於頂層，如果意識到該異常將導致頁面無法正常渲染，則應該直接跳轉到友好錯誤頁面，加上使用者容易理解的錯誤提示資訊。開發介面層需要異常處理成錯誤碼和錯誤資訊方式返回。
3.參考：分層領域模型規約：
）do （data object）：與資料庫表結構一一對應，通過 dao 層向上傳輸資料源物件。
）dto （data transfer object）：資料傳輸物件，service 或 manager 向外傳輸的物件。
）bo （business object）：業務物件。由 service 層輸出的封裝業務邏輯的物件。
）vo （view object）：顯示層物件，通常是 web 向模板渲染引擎層傳輸的物件。
）query ：資料查詢物件，各層接收上層的查詢請求。注意【強制】如果是超過兩個引數的查詢封裝，則禁止使用 map 來傳輸。
企業應用架構 分層
1 企業應用的特點是什麼？在我的概念裡，企業應用是與網際網路應用相對而言的，企業應用一般都是內網環境，網路的頻寬不用考慮，因此由於頻寬引起的效能一般可以不用考慮。資料量不大，但是資料很雜，資料與資料之間的關係很複雜。另外業務邏輯也沒有網際網路應用那麼簡單，一般也是很雜，很 2 企業應用在架構上需要考...
分層應用 怎樣實現登入？
三層這個階段的學習主要是靠自學，但從網上找到的相關資料 部落格都是零散的，沒有體系。資料看了不少，但一直沒有乙個大概的輪廓。查到的資料都是理論性的，那如何在詳細的樣例中實現分層呢？導圖之後就是詳細的小樣例。以初識三層中登入的小樣例為例，來看看分層的詳細應用吧。主要步驟 使用者在登入介面輸入usern...
編碼規約之應用分層
目錄 一 推薦 1.分層規約 二 參考 1.分層異常處理規約 2.分層領域模型規約 下圖中預設上層依賴於下層，箭頭關係表示可直接依賴。如 開放介面層可以依賴於 web 層，也可以直接依賴於 service 層，依此類推 開放介面層 可直接封裝 service 方法暴露成 rpc 介面 通過 web ...