我曾經一直用域模型和事務處理腳本模型設計應用程序。但是有一次我聽說JAVA企業應用程序可以用第三種途徑來實現，這種途徑就是Fowler所說的表模型設計模式。這種模式比事務處理腳本模式更加的結構化，因為它為數據庫中的每個表都寫了一個類，而這個類中實現了所有對這個表的操作代碼，這個類就是表模型類。(我的解釋就是為每個表專門寫個類，對表的所有操作，全都由這個類中的方法實現，相當于用一個類模擬的數據庫中的表)。和事務處理腳本模式相比，它將數據和行為分別封裝到了不同的類中，因為表模型類的實例相當于真實數據庫中的數據，這當然要比單獨的一條記錄要好的多。最后，可維護性成了問題，然而表模型設計模式還是有一些好處的。
決策2：封裝業務邏輯
前面幾章，我沒有提及如何組織業務邏輯。你必須決定業務邏輯有什么樣的接口。業務邏輯的接口由一些數據和方法組成，這些數據和方法由表示層來調用。在設計接口時重點需要考慮的是：應該封裝哪些業務邏輯的操作，而哪些操作不應該顯示給表示層。封裝接口可以提高程序的可維護性，因為通過隱藏業務邏輯的操作細節，可以實現修改業務邏輯而不影響表示層。缺點是，你必須為封裝業務邏輯而特意的寫很多的代碼。
你還需要考慮其他重要的問題，比如如何處理事務處理，安全，和遠程調用問題。通常這些也是業務邏輯接口要負責的問題。為了保證數據的連貫性，業務層的接口必須保證每個事務處理中的調用都能執行。同樣，也要驗證調用者是否有權限調用業務方法。業務層接口還要負責處理一些遠程客戶端的問題來考慮一下選項。
EJB session façade
經典的J2EE解決方案是：用EJB來封裝業務邏輯-基本的session facade.EJB容器提供事務處理管理，安全，分布式事務處理和遠程訪問。Facade方式可以通過封裝業務邏輯來提高程序可維護性。粗糙型(Coarse-grained) API通過減少表示層對業務層的訪問次數，而提高性能(因為它將對各個業務流程的處理再封裝了一次，所以對底層的業務流程來說，它的API是比較粗糙的，這里也許翻譯的不好。請大家見諒)。因為減少調用的次數，可以減少對數據庫事務處理的次數，還可以提高對象在緩沖區的機會。如果表示層通過遠程訪問業務層，則這種API還可以減少網絡負擔。圖表4給出了一個EJB-based session facade的例子。
Figure 4. Encapsulating the business logic with an EJB session façade
在這種設計模式中，表示層也許是通過遠程來調用facade(相當于session的一個高級接口)，EJB容器從facade中得到這個調用，并驗證調用者的權限，然后開始一個業務處理。這個時候facade調用底層的業務對象，而這些業務對象負責實現具體的業務邏輯。等Facade返回后，EJB容器提交業務處理或者讓該業務處理循環等待。
不幸的是，使用EJB session facade有一些嚴重的缺點。比如，EJB的會話bean只能在EJB容器中運行，這樣就托慢了開發和測試周期。另外，如果用EJB2，則用來向表示層傳輸數據的數據傳輸對象的開發和維護就會變的很枯燥而且曠日持久。
POJO facade
對于許多程序來說，更好的實現途徑是用POJO facade和AOP協作。比如負責管理事務處理、表示層的連接和安全問題的Spring 構架。POJO facade對業務層的封裝風格和EJB facade很相似，通常也可以用一樣的公共方法。而POJO和EJB關鍵區別是用POJO代替了EJB，用AOP提供的服務(例如業務處理管理和安全機制)替代了EJB容器。表5中，顯示了用POJO facade的例子。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
