業務邏輯和數據庫訪問決策

    這里有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和其他一些輕量級概念，所以對兩者（指輕量級和重考鍛揪叮┑那植皇嗆芮宄＞俑隼櫻琍OJO中的實體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.）中判定應該添加那種新特性要簡單的多。理論上你仍然需要刻意的為你的軟件設計最合適的業務邏輯。究竟我相信你有過修改別人垃圾結構代碼的慘痛經驗