J2EE中的商務邏輯和資料庫訪問決策說明

這裡有2種完全不同的方法來設計JAVA企業程式，其中一種選擇是採用標準EJB2實現途徑(approach)。我更願意稱這種方法為重量級實現途徑，當你使用重量級實現途徑時你需要用會話beans(session bean)和訊息驅動 beans(message-driven bean)去實現商務邏輯。你也可以使用DAOs(data access object)或者實體bean去訪問商務邏輯

另外一種選擇是使用POJOs 和輕量級構架，這種方式我稱為POJO實現途徑。當使用POJOs實現途徑時，你的商務邏輯完全由POJO來實現。你可以使用持久型構架又叫做對象/關係映射構架(a.k.a=also know as )例如Hibernate 或者 JDO來訪問資料庫，再用Spring AOP(面向層面編程)來提供企業服務，比如交易管理和安全。

EJB3由於融合了POJOs和其他一些輕量級概念，所以對兩者(指輕量級和重考鍛揪叮┑那�分不是很清楚。舉個例子，POJO中的實體bean既可以再EJB容器內運行，也可以再EJB容器外運行，然而POJOs中的會話bean和訊息驅動bean仍然有重量級的行為，因為他們只能在EJB容器內部運行。所以，顯而易見的，EJB3既是重量級的又有POJO的特性。EJB3中的實體bean是輕量級實現途徑中的一部分。

在開發過程中，首要的是從各種各樣的設計中選擇到底採用重量級實現途徑還是採用POJO實現途徑。決策可以影響程式的幾個方面，包括商務邏輯結構和資料訪問機制。為了協助從兩種實現途徑中擇其一，來看這張典型的公司專屬應用程式程式結構圖，結構圖在圖示1中，而且在設計過程中就必須判斷到底使用那種策略。

Figure 1. A typical application architecture and the key business logic and database access design decisions.

程式由網路基本展示層、業務層、持久層組成。網路基本展示層負責HTTP請求和為一般的瀏覽器用戶端、XML和其他的胖體用戶端產生HTML，比如為Ajax基本用戶端產生HTML.業務層被展示層調用，用來實現程式商務邏輯。持久層被商務邏輯層用來訪問外部資料源，比如資料庫和其他程式。

展示層的設計不在本篇文章討論之內，來看圖表的其他部分，我們需要決定業務層結構的介面，這個介面是提供給展示層以及其他用戶端的。而且還需要決定怎樣訪問能供多個程式訪問的資料庫。我們還必須決定如何處理短期交易處理事務和長期交易處理事務的並發問題。這些加起來一共有5種決策。每種決策都是要設計者來制定，為了能看懂示範圖(big picture)要求每個開發人員也都瞭解這些策略。

這些決策直接決定程式業務和展示層設計的特點。當然，還要決定一些其他很重要的決策。比如業務處理(transactions)、安全問題、緩衝問題以及如何整合程式，但是關於這些問題通常在其他文獻中討論在圖表1中顯示的五種決策，每種決策都有多種選擇。每種選擇根據它要解決的實際問題都有相應的優缺點。後續章節中，你會發現每種決策針對一個或多個領域時，在功能性、易開發性、可維護性和可用性方面有不同的平衡點。儘管我是POJO實現途徑的超級大FANS，但是仍然需要瞭解其優缺點，以便於為你的程式做最好的選擇下面我們來瞭解一下每種決策的大綱和其選項。

決策1：組織商務邏輯

現在，很多的注意力都集中在某項技術的優點和缺點，儘管這很重要，但是在本質上你需要瞭解如何建構你的商務邏輯。如果不考慮如何組織就去寫代碼是非常簡單的。例如，為一個會話BEAN添加代碼要比在域模式(domain model.： An object model of the domain that incorporates both behavior and data.)中判斷應該添加那種新特性要簡單的多。理論上你仍然需要刻意的為你的軟體設計最合適的商務邏輯。畢竟我相信你有過修改別人垃圾結構代碼的慘痛經驗

關鍵的決策是：到底應該用物件導向的實現途徑還是面向過程的實現途徑來實現你的程式。這個不是關於技術的決策，但是你技術上的決策可以潛在的約束你的商務邏輯的組織圖。採用EJB2技術，有利於面向過程設計，然而POJOs和輕量級構架可以讓你為特殊的程式選擇最好的實現途徑

採用過程式設計

雖然我是一個物件導向實現途徑(指前文的使用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或者其他非物件導向語言的話，你應該用過這種設計模式。如果這種模式很適合你的設計的話，用這種模式設計也是一種不錯的選擇。

這種直觀的過程式開發途徑，非常的誘人，因為你只需要寫代碼就好了，不用考慮如何組織你的類檔案。但問題是，如果你的商務邏輯非常的複雜，那麼你的代碼會變的噩夢般的難以維護。所以，除非你要寫的程式非常的簡單，否則你應該用物件導向設計你的程式，而不要受面向過程的代碼的誘惑。