轉載：談J2EE架構分層：業務邏輯層不是轉發器

此文乃好文，轉之。

原文：[url]http://www.cnblogs.com/xiaoluojava/archive/2010/05/07/1729992.html[/url]

我們今天來談談J2EE架構分層---主要想談的是業務邏輯層不是轉發器。

　　在Java EE的開發中，我們一直強調J2EE架構分層，什麼MVC三層體系，N層架構，好像隻有架構分層越多，系統就越完美，才能展現出現代軟體工程的優點。最近一直在思考，我們為什麼要分層？分層的意義何在？怎樣去組織各個層次的關系？

架構分層的好處就在于代碼清晰，結構分明，有利于修改、維護和複用，這已經成為大家分層的一個最有說服力的原因。但是也并不是任何系統都要分層設計，簡單的系統，可以選擇較少的層，反而可以開發效率和系統運作的效率。特别在需求不斷更新和未知的web開發中，架構分層也并不能給我們帶來多少實質性的好處，反而增加的複雜度而不能及時響應需求。

但在大型的企業級開發中，我們通常要進行架構分層設計，而表現層、業務邏輯層、資料操作層是我們最普遍的層次劃分，如下圖所示。在表現層上，我們已經習慣了MVC的體系，常使用Struts，JSF等架構。而在MVC的體系中C是其中的核心，我們在這裡用Action來表示，它處理用戶端發送的請求并根據業務的流程進行轉發。而實際的業務處理，則交給Service處理。我們常使用Spring、EJB去做這一層的架構。而資料持久層，JPA的标準，Hibernate、Toplink等ORM架構已經被我們越來越多的使用。

　　在J2EE架構分層體系中，我一直在思考，誰才是核心，哪一層才是系統最關注的部分。當然大家都很明白，業務才是系統核心，一切随業務的變化而改變。但是在實際的開發中，我卻看到很多這樣的現象，包括發生在自己身上的。我們過多的關注了表現層和DAO層，業務的變更最直覺的展現是表現在頁面上，表現層的變化是必須得，但是表現層的變化更多的展現在流程的變化。我們也經常喜歡去過度的處理DAO層，業務的變更直接展現到SQL上的變更，一個個業務邏輯被翻譯成一條條複雜的SQL語句。而這些導緻的結果是什麼，Service層成為可有可無的雞肋，它存在的意義完全成了連接配接Action和DAO的簡單橋梁。以下代碼确實反映了這個問題。

public A saveA(A a){
    return this.aDAO.saveA(a);
}
public List<A> getAs(String a,String b){
    return this.aDAO.getAs(a,b);
}
……
           

我們在開發的時候，雖然劃分了Service層，但是這隻是對DAO的簡單調用，Service成了絕對的輕量級。有時候頁面上需要一個幾十行的list，隻是由于分成了幾塊展示，而我們經常按照這幾塊去一次次的查詢資料庫，而不去試着讓Service調用一次資料庫取到所有的記錄，然後通過一定得政策去分解這些記錄。難道企業的開發隻是資料庫的操作？Java的運算性能難道隻展現在SQL的優化上？這樣的架構分層還不如不分，業務層也沒有必要。

還是讓我們回歸Service的本來面目吧，讓我們将action和DAO的部分功能向Service轉移吧。Action隻負責接受請求，調用具體的Service，進行處理後轉發；DAO可以使用更精簡的，更通用的方法處理所有資料的持久和查詢，隻需要封裝最基本的增删改查就OK了。讓Action和DAO盡可能的輕量級，隻關注本身，而非業務。讓業務層來處理更多的内容吧。如下是業務處理的方法。

public void saveA(A a){
    //儲存前某業務邏輯的驗證，如資料合法性檢查，業務規則驗證
    this.aDAO.saveA(a);
    //儲存完想JMS發送消息，通知使用者已經處理
}
           

有人認為架構分層不好是因為一個地方改變，需要維護好多層，其實這是沒有有效的使用架構分層，DAO和action層存在了過多的業務邏輯的處理，業務的改變當然會造成動一處而牽全身的後果。關注Service層，解放action和dao，保持action和dao的高度穩定性，利用穩定的業務接口和IoC等松散耦合的處理進行層層的互動，讓程式人員更多的關注業務本身，而非其他的繁枝末節，這才是我們架構分層的目的。

但是在開發中的确面臨着這樣的問題，除了複雜的業務邏輯，Service中必不可少的需要簡單的增删改查的簡單調用，怎樣才能讓Service從中解放出來，讓我們更多的關注真實的業務操作，這是下次要思考和讨論的問題。