采用過程式設計
雖然我是一個面向對象實現途徑(指前文的使用POJO和LIGHTFRAMEWORK)的倡導者，但是有些情況下面向對象實現途徑有些大材小用，比如你只想實現一個非常簡單的業務邏輯。而且，有時候，面向對象實現途徑不太可行-—比如，你沒有持久層構架來將你的對象映射到數據庫中，在這種情況下，更好的方法是編寫面向過程的代碼，而且采用Martin Fowler稱作事務腳本(Transaction Script)的設計模式，要比采用面向對象實現途徑設計要好，因為你只需要寫一個方法來調用事務處理腳本去處理表示層的請求。
采種這種實現途徑的一個很重要的特點是，用于實現某種行為的類和數據存儲區是分開的。在EJB2的應用程序中，這種方式的業務邏輯和圖表2中的設計是非常相似的。這種設計的核心全都集中在EJB或者POJO的行為上，因為他們實現了事務腳本，并且還操作那些 “啞”對象數據(因為他們只擁有很少的行為，大部分都是數據)。因為大部分的行為都集中在少量的大型類上，所以代碼會變的很難理解與維護。
Figure 2. The structure of a procedural design： large transaction script classes and many small data objects
這種設計具有高面向過程的特性，而且基本不依靠面向對象語言的特性。如果你曾經使用過C或者其他非面向對象語言的話，你應該用過這種設計模式。如果這種模式很適合你的設計的話，用這種模式設計也是一種不錯的選擇。
這種直觀的過程式開發途徑，非常的誘人，因為你只需要寫代碼就好了，不用考慮如何組織你的類文件。但問題是，如果你的業務邏輯非常的復雜，那么你的代碼會變的噩夢般的難以維護。所以，除非你要寫的程序非常的簡單，否則你應該用面向對象設計你的程序，而不要受面向過程的代碼的誘惑。
采用面向對象設計
在面向對象設計中，業務邏輯是由對象模型構成的，對象模型是由許多小類組成的關系網。這些類直接體現的是問題域的解決方法，如圖3所示，在這種模式中，有些類只有數據，有些類只有行為，但是大多數的則兩者都有，這是優秀的類設計的一種特點。
Figure 3. The structure of a domain model： small classes that have state and behavior
面向對象設計有許多的好處，包括可以提高可維護性和可延展性。你可以用EJB2的實體bean來實現一個簡單的對象模型。但是如果像要獲得更多的好處的話，必須要使用POJOs技術和輕量級持久層構架——比如Hibernate和JDO技術。POJO可以讓你開發豐富的模型，這些模型可以擁有繼承和回調等特點。而輕量級持久層構架可以讓你很簡單的從對象模型映射到數據庫。
對象模型的另外一個名字是域模型，Fowler稱這種由面向對象途徑來開發的業務邏輯叫做域模型設計模式。(就是類的設計是直接用來解決問題的，則這種設計模式叫做域模型設計模式)
表模型設計模式
我曾經一直用域模型和事務處理腳本模型設計應用程序。但是有一次我聽說JAVA企業應用程序可以用第三種途徑來實現，這種途徑就是Fowler所說的表模型設計模式。這種模式比事務處理腳本模式更加的結構化，因為它為數據庫中的每個表都寫了一個類，而這個類中實現了所有對這個表的操作代碼，這個類就是表模型類。(我的解釋就是為每個表專門寫個類，對表的所有操作，全都由這個類中的方法實現，相當于用一個類模擬的數據庫中的表)。和事務處理腳本模式相比，它將數據和行為分別封裝到了不同的類中，因為表模型類的實例相當于真實數據庫中的數據，這當然要比單獨的一條記錄要好的多。最后，可維護性成了問題，然而表模型設計模式還是有一些好處的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
