J2EE中MVC的各層的設計原則及其編寫注意事項

總結了下J2EE的MVC模式開發原則，很多細節處理好了是很有利于開發與維護的。

下面就從各層說起。

視圖層

主要是用戶端的顯示，主要是JSP和HTML，随着Web的不斷發展，許多基于Javascript的富應用用戶端不斷出現，越來越流行通過JSON格式進行前背景資料互動。

控制層：

Control：

作為處理分發器，組裝前台需要的資料給用戶端。

服務層（Service 業務邏輯層）：

存放業務控制，在Service層中将dao的操作組合起來放入事務中。操作檔案之類的都放到Service中。

Service中盡量複用dao中的操作，涉及到一張表産生的業務放入到dao中。

VO（Value Object，ViewObject）是符合Java Bean屬性規範的簡單Java對象，由new關鍵字建立，由業務邏輯使用，為資料提供一個生存的地方。主要對應界面顯示資料的對象，用一個VO對應一個請求的所有資料。

Dao（資料通路層）：

dao：

存放基本的操作，真正起到資料庫的操作。

Dao隻能操作單表，跨表的操作，放到Service中。

Model：

一般來所一張表對應一個Model，一些中間表就不用建立Model，可以把中間表操作的相關方法直接寫到和中間表相關的Model中。

Domain：

是一個範圍，接線，作為一個領域，常放到一個包中。

　　分層的好處：架構與管理，增加可維護性。這裡特别強調的就是命名規範。先架構再編碼。

分層開發遵守的原則：

① 上層依賴于下層，依賴關系不跨層；

② 一切設計都從Service層出發，作為一個系統首先需要把握其業務。從系統需要提供的功能進行分析，來确定Service接口中的方法，而不是從資料庫出發到dao和Domain，再到Service層。不要對系統分層産生了誤解，還是從最重要的功能來考慮的；

③ 事務控制放到Service中；

④ Service層的設計，需要考慮控制Service的數量，通常将一個子產品的服務放到一個Service中來處理，從Service層往下看，接口逐漸增多；

⑤ 服務層的實作依賴于領域活動。最核心的設計就是将系統中的實體劃分為領域模型，在此基礎上設計dao層，再把這些操作暴露給Service層；

⑥ 每一個接口的職責範圍有明确目的。這樣設計是有問題的：一表對應一個dao，一個dao對應一個domain，一個domain對應一個Service，導緻Service接口和dao的接口基本一緻。最終Service裡面太多的方法，然後，隻能在Control層中反複調用Service，這樣的代碼是不堪入目的。可以這樣做，一個domain活動聚合對應的一組dao來完成領域活動，而在Service也可能包含兩個domain活動；

⑦ 每一個層中的接口都關注自己的那一塊，不能在一個Dao中随意操作别的表，這樣隻能讓項目更加難以維護。