1.ORMhtml
2.DAO程序員
DAO(數據訪問對象)是一種應用程序編程接口(API),存在於微軟的Visual Basic中,它容許程序員請求對微軟的Access數據庫的訪問。DAO是微軟的第一個面向對象的數據庫接口。DAO對象封閉了Access的Jet函數。經過Jet函數,它還能夠訪問其餘的結構化查詢語言(SQL)數據庫。web
J2EE開發人員使用數據訪問對象(DAO)設計模式把底層的數據訪問邏輯和高層的商務邏輯分開.實現DAO模式可以更加專一於編寫數據訪問代碼.數據庫
咱們先來回顧一下DAO設計模式和數據訪問對象.編程
DAO基礎設計模式
DAO模式是標準的J2EE設計模式之一.開發人員使用這個模式把底層的數據訪問操做和上層的商務邏輯分開.一個典型的DAO實現有下列幾個組件:瀏覽器
1. 一個DAO工廠類;服務器
2. 一個DAO接口;數據結構
3. 一個實現DAO接口的具體類;app
4. 數據傳遞對象(有些時候叫作值對象).
具體的DAO類包含了從特定的數據源訪問數據的邏輯。在下面的這段中你將學到設計和實現數據訪問對象的技術。
事務劃分:
關於DAO要記住的一件重要事情是它們是事務性對象。每一個被DAO執行的操做(對象建立,更新、或刪除數據)都是和事務相關聯的。一樣的,事務劃分(transaction demarcation)的概念是特別重要的。
事務劃分是在事務界定定義中的方式。J2EE規範爲事務劃分描述了兩種模式:編程性事務(programmatic)和聲明性事務(declarative).下表是對這兩種模式的拆分:
聲明性事務劃分 編程性事務劃分
程序員使用EJB的佈署描述符聲明事務屬性 程序員擔負編寫事務邏輯代碼的責任。
運行時環境(EJB容器)使用這些屬性來自動的管理事務。應用程序經過一個API接口來控制事務。
3.MVC
MVC英文即Model-View-Controller,即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離,這樣一個應用被分紅三個層——模型層、視圖層、控制層。
視圖(View)表明用戶交互界面,對於Web應用來講,能夠歸納爲HTML界面,但有可能爲XHTML、XML和Applet。隨着應用的複雜性和規模性,界面的處理也變得具備挑戰性。一個應用可能有不少不一樣的視圖,MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理,以及用戶的請求,而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。好比一個訂單的視圖只接受來自模型的數據並顯示給用戶,以及將用戶界面的輸入數據和請求傳遞給控制和模型。
模型(Model):就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來講是黑箱操做,模型接受視圖請求的數據,並返回最終的處理結果。業務模型的設計能夠說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子,它從應用技術實現的角度對模型作了進一步的劃分,以便充分利用現有的組件,但它不能做爲應用設計模型的框架。它僅僅告訴你按這種模型設計就能夠利用某些技術組件,從而減小了技術上的困難。對一個開發者來講,就能夠專一於業務模型的設計。MVC設計模式告訴咱們,把應用的模型按必定的規則抽取出來,抽取的層次很重要,這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠,也不能太近。MVC並無提供模型的設計方法,而只告訴你應該組織管理這些模型,以便於模型的重構和提升重用性。咱們能夠用對象編程來作比喻,MVC定義了一個頂級類,告訴它的子類你只能作這些,但無法限制你能作這些。這點對編程的開發人員很是重要。
業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據 保存(持續化)。好比將一張訂單保存到數據庫,從數據庫獲取訂單。咱們能夠將這個模型單獨列出,全部有關數據庫的操做只限制在該模型中。
控制(Controller)能夠理解爲從用戶接收請求, 將模型與視圖匹配在一塊兒,共同完成用戶的請求。劃分控制層的做用也很明顯,它清楚地告訴你,它就是一個分發器,選擇什麼樣的模型,選擇什麼樣的視圖,能夠完成什麼樣的用戶請求。控制層並不作任何的數據處理。例如,用戶點擊一個鏈接,控制層接受請求後, 並不處理業務信息,它只把用戶的信息傳遞給模型,告訴模型作什麼,選擇符合要求的視圖返回給用戶。所以,一個模型可能對應多個視圖,一個視圖可能對應多個模型。
模型、視圖與控制器的分離,使得一個模型能夠具備多個顯示視圖。若是用戶經過某個視圖的控制器改變了模型的數據,全部其它依賴於這些數據的視圖都應反映到這些變化。所以,不管什麼時候發生了何種數據變化,控制器都會將變化通知全部的視圖,致使顯示的更新。這其實是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關係和各自的主要功能,如圖1所示。
ASP.NET提供了一個很好的實現這種經典設計模式的相似環境。開發者經過在ASPX頁面中開發用戶接口來實現視圖;控制器的功能在邏輯功能代碼(.cs)中實現;模型一般對應應用系統的業務部分。在ASP.NET中實現這種設計而提供的一個多層系統,較經典的ASP結構實現的系統來講有明顯的優勢。將用戶顯示(視圖)從動做(控制器)中分離出來,提升了代碼的重用性。將數據(模型)從對其操做的動做(控制器)分離出來可讓你設計一個與後臺存儲數據無關的系統。就MVC結構的本質而言,它是一種解決耦合系統問題的方法。
視圖是模型的表示,它提供用戶交互界面。使用多個包含單顯示頁面的用戶部件,複雜的Web頁面能夠展現來自多個數據源的內容,而且網頁人員,美工能獨自參與這些Web頁面的開發和維護。
在ASP.NET下,視圖的實現很簡單。能夠像開發WINDOWS界面同樣直接在集成開發環境下經過拖動控件來完成頁面開發本。本文中介紹每個頁面都採用複合視圖的形式即:一個頁面由多個子視圖(用戶部件)組成;子視圖能夠是最簡單HTML 控件、服務器控件或多個控件嵌套構而成的Web自定義控件。頁面都由模板定義,模板定義了頁面的佈局,用戶部件的標籤和數目,用戶指定一個模板,平臺根據這些信息自動建立頁面。針對靜態的模板內容,如頁面上的站點導航,菜單,友好連接,這些使用缺省的模板內容配置;針對動態的模板內容(主要是業務內容),因爲用戶的請求不一樣,只能使用後期綁定,而且針對用戶的不一樣,用戶部件的顯示內容進行過濾。使用由用戶部件根據模板配置組成的組合頁面,它加強了可重用性,並原型化了站點的佈局。
視圖部分大體處理流程以下:首先,頁面模板定義了頁面的佈局;頁面配置文件定義視圖標籤的具體內容(用戶部件);而後,由頁面佈局策略類初始化並加載頁面;每一個用戶部件根據它本身的配置進行初始化,加載校驗器並設置參數,以及事件的委託等;用戶提交後,經過了表示層的校驗,用戶部件把數據自動提交給業務實體即模型。
這一部分主要定義了WEB頁面基類PageBase;頁面佈局策略類PageLayout,完成頁面佈局,用於加載用戶部件到頁面;用戶部件基類UserControlBase即用戶部件框架,用於動態加載檢驗部件,以及實現用戶部件的個性化。爲了實現WEB應用的靈活性,視圖部分也用到了許多配置文件例如:置文件有模板配置、頁面配置、路徑配置、驗證配置等。
爲了可以控制和協調每一個用戶跨越多個請求的處理,控制機制應該以集中的方式進行管理。所以,爲了達到集中管理的目的引入了控制器。應用程序的控制器集中從客戶端接收請求(典型狀況下是一個運行瀏覽器的用戶),決定執行什麼商業邏輯功能,而後將產生下一步用戶界面的責任委派給一個適當的視圖組件。
用控制器提供一個控制和處理請求的集中入口點,它負責接收、截取並處理用戶請求;並將請求委託給分發者類,根據當前狀態和業務操做的結果決定向客戶呈現的視圖。在這一部分主要定義了HttpReqDispatcher(分發者類)、HttpCapture(請求捕獲者類)、Controller(控制器類)等,它們相互配合來完成控制器的功能。請求捕獲者類捕獲HTTP請求並轉發給控制器類。控制器類是系統中處理全部請求的最初入口點。控制器完成一些必要的處理後把請求委託給分發者類;分發者類分發者負責視圖的管理和導航,它管理將選擇哪一個視圖提供給用戶,並提供給分發資源控制。在這一部分分別採用了分發者、策略、工廠方法、適配器等設計模式。
爲了使請求捕獲者類自動捕獲用戶請求並進行處理,ASP.NET 提供低級別的請求/響應 API,使開發人員可以使用 .NET 框架類爲傳入的 HTTP 請求提供服務。爲此,必須創做支持 System.Web.IHTTPHandler 接口和實現 ProcessRequest() 方法的類即:請求捕獲者類,並在web.config 的 <httphandlers> 節中添加類。ASP.NET 收到的每一個傳入 HTTP 請求最終由實現 IHTTPHandler 的類的特定實例來處理。IHttpHandlerFactory 提供了處理 IHttpHandler 實例 URL 請求的實際解析的結構。HTTP 處理程序和工廠在 ASP.NET 配置中聲明爲 web.config 文件的一部分。ASP.NET 定義了一個 <httphandlers> 配置節,在其中能夠添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory 和 HttpHandler 的設置。 HTTP 處理程序和工廠是 ASP.NET 頁框架的主體。工廠將每一個請求分配給一個處理程序,後者處理該請求。 例如,在全局 machine.config 文件中,ASP.NET 將全部對 ASPx 文件的請求映射到 HttpCapture類:
<httphandlers>
...
...
</httphandlers>
MVC系統中的模型從概念上能夠分爲兩類――系統的內部狀態和改變系統狀態的動做。模型是你全部的商業邏輯代碼片斷所在。本文爲模型提供了業務實體對象和業務處理對象:全部的業務處理對象都是從ProcessBase類派生的子類。業務處理對象封裝了具體的處理邏輯,調用業務邏輯模型,而且把響應提交到合適的視圖組件以產生響應。業務實體對象能夠經過定義屬性描述客戶端表單數據。全部業務實體對象都EntityBase派生子類對象,業務處理對象能夠直接對它進行讀寫,而再也不須要和request、response對象進行數據交互。經過業務實體對象實現了對視圖和模型之間交互的支持。實現時把"作什麼"(業務處理)和"如何作"(業務實體)分離。這樣能夠實現業務邏輯的重用。因爲各個應用的具體業務是不一樣的,這裏再也不列舉其具體代碼實例。
4.POJO
POJO(Plain Ordinary Java Object)簡單的Java對象,實際就是普通JavaBeans,是爲了不和EJB混淆所創造的簡稱。
使用POJO名稱是爲了不和EJB混淆起來, 並且簡稱比較直接. 其中有一些屬性及其getter setter方法的類,沒有業務邏輯,有時能夠做爲VO(value -object)或dto(Data Transform Object)來使用.固然,若是你有一個簡單的運算屬性也是能夠的,但不容許有業務方法,也不能攜帶有connection之類的方法。