天天看點

轉載:談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從中解放出來,讓我們更多的關注真實的業務操作,這是下次要思考和讨論的問題。