IT行業(yè)的一大特點是經(jīng)常創(chuàng)造一些新名詞，單層和雙層這兩個概
念就是在三層結構出現(xiàn)之后才創(chuàng)造出。單層結構是80年代以來小型應用的結構，典型的是基于Dbase、Foxbase等小型數(shù)據(jù)庫的應用。雙層結構的同義詞可以理解為傳統(tǒng)的客戶/服務器結構，是目前占統(tǒng)治地位的結構，典型是基于Oracle、Infomix等大型數(shù)據(jù)庫的應用。三層結構是傳統(tǒng)的客戶/服務器結構的發(fā)展，代表了企業(yè)級應用的未來，典型的有Web下的應用。多層結構和三層結構的含義是一樣的，只是細節(jié)有所不同。
之所以會有雙層、三層這些提法，是因為應用程序要解決三個層面的問題。
一：界面層
界面層提供給用戶一個視覺上的界面，通過界面層，用戶輸入數(shù)據(jù)、獲取數(shù)據(jù)。界面層同時也提供一定的安全性，確保用戶有會看到機密的信息。
二：邏輯層
邏輯層是界面層和數(shù)據(jù)層的橋梁，它響應界面層的用戶請求，執(zhí)行任務并從數(shù)據(jù)層抓取數(shù)據(jù)，并將必要的數(shù)據(jù)傳送給界面層。
三：數(shù)據(jù)層
數(shù)據(jù)層定義、維護數(shù)據(jù)的完整性、安全性，它響應邏輯層的請求，訪問數(shù)據(jù)。這一層通常由大型的數(shù)據(jù)庫服務器實現(xiàn)，如Oracle 、Sybase、MS SQl Server等。
三層架構的優(yōu)勢
從開發(fā)角度和應用角度來看，三層架構比雙層或單層結構都有更大的優(yōu)勢。三層結構適合群體開發(fā)，每人可以有不同的分工，協(xié)同工作使效率倍增。開發(fā)雙層或單層應用時，每個開發(fā)人員都應對系統(tǒng)有較深的理解，能力要求很高，開發(fā)三層應用時，則可以結合多方面的人才，只需少數(shù)人對系統(tǒng)全面了解，從一定程度工降低了開發(fā)的難度。
三層架構屬于瘦客戶的模式，用戶端只需一個較小的硬盤、較小的內(nèi)存、較慢的CPU就可以獲得不錯的性能。相比之下，單層或胖客戶對面器的要求太高。我的機器是奔騰133、32M內(nèi)存、2.5G硬盤，裝了IE4.0之后，感覺機器慢子很多，硬盤也只有300多M的空余空間了，已打算將硬盤擴充到4G。試想如果今后還是以單層或雙層峁刮主流的話，硬件的更新費用將會有多大，盡管現(xiàn)在電腦價格下降很多，對個人用戶已可以承受，但對于企業(yè)而言，頻繁的臺舊機器淘汰，換新機器，這是一筆多么大的費用
三層架構的另一個優(yōu)點在于可以更好的支持分布式計算環(huán)境。邏輯層的應用程序可以有多個機器上運行，充分利用網(wǎng)絡的計算功能。分布式計算的潛力巨大，遠比升級CPU有效。美國人曾利用分式計算解密，幾個月就破解了據(jù)稱永遠都破不了的密碼。
三層架構的最大優(yōu)點是它的安全性。用戶端只能通過邏輯層來訪問數(shù)據(jù)層，減少了入口點，把很多危險的系統(tǒng)功能都屏蔽了。
如何開發(fā)三層應用
支持三層應用開發(fā)的工具很多，VC 5.0、Delphi 3.0、VB 5.0都是不錯的選擇，而Delphi是其中功能強大而有相對容易的開發(fā)工具。
Delphi 3針對3層結構，提出了三種代理（Broker)和新一代的數(shù)據(jù)庫引擎，來適應它。
第一種叫Remote Data Broker, Remote Data Broker結構的精髓是讓每一個客戶端不再需要BDE，取面代之的是中央化的BDE，以集中管理的方式降低每一個客戶在BDE上所須調(diào)整的開銷和復雜度。第二種叫Constraint Broker，它所扮演的角色就是保證所有客戶數(shù)據(jù)的一致性和數(shù)據(jù)的完整性。第三種是Business Object Broker，它的目的是提供給一些關鍵性的商業(yè)應用程序一個快速而且可信賴的使用環(huán)境。為了達成這種高層次的要求，BusinessObjectBroker會自動的將應用程序做適當?shù)膭澐郑椭浦匾臉I(yè)務規(guī)則到第一個區(qū)間，以達到速度的要求
總結。
伴隨著企業(yè)自身的發(fā)展和外部環(huán)境的復雜化，企業(yè)的需求也越來越復雜，應用程序的開發(fā)也更加困難。三層客戶/服務器架構將有助于解決這一問題。
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
附錄詳細解釋：
1.1關于架構
架構這個詞從它的出現(xiàn)后,就有許許多多的程序員、架構師們激烈地討論著它的發(fā)展，但是架構一詞的出現(xiàn)，卻是隨著三層架構的出現(xiàn)才出現(xiàn)的。當然，目前應用三層架構開發(fā)也正是業(yè)界最關注的主題。那么這里我們來看看單層、雙層、三層甚至多層架構到底是怎么一回事。單層結構是80年代以來小型應用的結構，在那個結構化編程充斥的時代，還沒有出現(xiàn)架構的概念，典型的是基于Dbase、Foxbase等小型數(shù)據(jù)庫的應用。雙層結構的同義詞可以理解為傳統(tǒng)的客戶/服務器結構，盡管目前占統(tǒng)治地位的結構，但是其封裝移植等方面的缺陷，已使它步入暮年，典型是基于Oracle、Infomix等大型數(shù)據(jù)庫的C/S應用。三層結構是傳統(tǒng)的客戶/服務器結構的發(fā)展，代表了企業(yè)級應用的未來，典型的有Web下的應用。多層結構和三層結構的含義是一樣的，只是細節(jié)有所不同。 之所以會有雙層、三層這些提法，是因為應用程序要解決三個層面的問題。
1.2三層架構概述
隨著軟件工程的不斷進步和規(guī)范以及面向?qū)ο缶幊趟枷氲膽茫藗儗Ψ庋b、復用、擴展、移置等方面的要求，使得雙層架構顯然更加臃腫繁瑣，三層程序架構體系應運而生，可以說，三層架構體系結構是面向?qū)ο笏枷氚l(fā)展中的必然產(chǎn)物。當然三層架構對于目前來說早已經(jīng)不是什么新鮮事物了,最早聽到這個詞應該是幾年前使用java知道的吧， j2ee三層架構體系流行了這么多年，一直沒有使用過,不過j2ee三層架構體系的提出，對軟件系統(tǒng)的架構產(chǎn)生了巨大的影響，Microsoft、Boland這些公司自然不甘落后，例如Microsoft的.net平臺，更有甚者，稱.net之c#為java的兒子。那么何謂三層架構？所謂三層架構，是在客戶/服務之間加入了一個"中間層"，也叫組件層。它與客戶層、服務器層共同構成了三層體系。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不僅僅有B/S應用才有三層體系結構，三層是指邏輯上的三層。通過引入中間層，將復雜的商業(yè)邏輯從傳統(tǒng)的雙層結構(Client-Server)應用模型中分離出來，并提供了可伸縮、易于訪問、易于管理的方法，可以將多種應用服務分別封裝部署于應用服務器，同時增強了應用程序可用性、安全性、封裝復用性、可擴展性和可移置性，使用戶在管理上所花費的時間最小化，從而實現(xiàn)了便捷、高效、安全、穩(wěn)定的企業(yè)級系統(tǒng)應用。
1.3分層描述三層架構
三層體系的應用程序?qū)I(yè)務規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是中間層向外提供接口，通過COM/DCOM通訊或者Http等方式與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進行交互。當然數(shù)據(jù)通過中間層的中轉(zhuǎn)無疑是降低了效率，但是它脫離于界面與數(shù)據(jù)庫的完美封裝，使得它的缺點顯然不值得一提。
典型的三層結構分為表示（presentation）層, 領域（domain）層, 以及基礎架構（infrastructure）層，而微軟的DNA架構定義了三個層：表示層（presentation），業(yè)務層（business），和數(shù)據(jù)存儲層（data access），當然J2ee 也有它不同的分法不過都大同小異吧。既然我用.net做的開發(fā)，這大三層我無需多說了,根據(jù)我的理解，我對此做了更詳細的分層,界面外觀層、界面規(guī)則層、業(yè)務接口層、業(yè)務邏輯層、實體層、數(shù)據(jù)訪問層、數(shù)據(jù)存儲層共七層，其具體的調(diào)用如圖1所示:
圖1
由圖1可以看出，雖然我將系統(tǒng)的架構分為七層，實際上大的方面來說，它就是一個典型的三層架構設計思想。單從這個圖來看，數(shù)據(jù)的調(diào)用顯得繁瑣而抽象，也許這時候就會有人說，我只是想實現(xiàn)界面上與用戶交互，然后根據(jù)用戶的請求將數(shù)據(jù)讀出/寫入數(shù)據(jù)庫就好了，為什么要做如此復雜的分層調(diào)用呢？從這個問句中我們也只看到了界面和數(shù)據(jù)庫，也就是說從用戶的需求來說，就是這兩層而已，但是這里我們首先要搞清楚的是三層架構它主要是為程序員為了實現(xiàn)部署、開發(fā)、維護企業(yè)級數(shù)據(jù)庫系統(tǒng)而服務的。如果我們在中間層實現(xiàn)了對表示層和數(shù)據(jù)庫層的完全脫離，其部署、開發(fā)、維護系統(tǒng)的費用和時間至少降低到原來的一半，甚至更多。
1.4部署企業(yè)級數(shù)據(jù)庫應用
對于一個企業(yè)級數(shù)據(jù)庫應用系統(tǒng)上的三層架構我是這樣部署的：
系統(tǒng)通過瀏覽器或應用程序客戶端提供與用戶的交互平臺，并向服務器提交請求（界面外觀層）；用戶提交請求后，界面規(guī)則層對用戶的數(shù)據(jù)按照業(yè)務邏輯層要求的接口參數(shù)封裝規(guī)則封裝用戶數(shù)據(jù)，然后調(diào)用業(yè)務接口層對外提供的相應命令接口（界面規(guī)則層），業(yè)務接口層通過對數(shù)據(jù)進行解析并分別送入不同的邏輯處理并向用戶返回處理結果(業(yè)務接口層)；對于數(shù)據(jù)和命令的不同，處理方式也不同，我們將不同的處理方式都歸類，并將接口層傳入的數(shù)據(jù)及命令流入對應處理流程（業(yè)務規(guī)則層）；這時，不同的處理流程分析數(shù)據(jù)和命令產(chǎn)生出對應的一個實體，這個實體根據(jù)其本身的屬性和方法以及上層傳入的命令，將數(shù)據(jù)處理為數(shù)據(jù)訪問層需要的接口參數(shù)，并向數(shù)據(jù)訪問層提交訪問數(shù)據(jù)庫的請求，并向業(yè)務接口層返回訪問結果（實體層）；數(shù)據(jù)訪問層會將數(shù)據(jù)轉(zhuǎn)化為數(shù)據(jù)庫可識別的語句（SQL），并訪問數(shù)據(jù)庫層，訪問結果會返回給實體層（數(shù)據(jù)訪問層）；數(shù)據(jù)庫層處理上層傳入的SQL，讀寫數(shù)據(jù)庫內(nèi)置對象，并根據(jù)其內(nèi)置對象本身的關系對數(shù)據(jù)做進一步校驗和處理（數(shù)據(jù)庫層）。這里我所講到的企業(yè)級數(shù)據(jù)庫應用系統(tǒng)，不論它是基于B/S應用系統(tǒng)上的三層架構設計，還是基于C/S應用系統(tǒng)上的三層架構設計，基本上是一樣的，所不同的只是兩種方式常用的數(shù)據(jù)傳輸協(xié)議的不同，B/S應用系統(tǒng)設計一般數(shù)據(jù)傳遞是通過HTTP來完成的，C/S應用系統(tǒng)設計則更多的是基于TCP/IP協(xié)議來傳送數(shù)據(jù)的，當然，隨著企業(yè)級應用系統(tǒng)對安全性方面要求的要求越來越高，更多的防火墻架設于物理線路之間，C/S應用系統(tǒng)的設計也越來越多地趨向于HTTP，典型的方式如：
CLIENTàISAPI/CGIàServer Database；
CLIENTàWeb ServiceàServer Database；
既然提到這兩種方式，我簡單地提一下它們兩者的區(qū)別及應用，它們的不同主要是中間層向客戶端提供服務的方式不同，一般情況下這兩種方式都需要架設專門用于受理客戶端請求的Web Server，很明顯，它更進一步地體現(xiàn)了三層架構的安全性。中間層基于ISAPI/CGI的方式可以說正在被Web Service方式所取代，這也正是面向?qū)ο笏枷氲倪M一步應用。ISAPI/CGI向客戶端提供的服務實際上是遠程調(diào)用函數(shù)，數(shù)據(jù)一般由程序員自定義結構存儲，并基于HTTP與Web Server交互，而Web Service向客戶端提供的服務是遠程調(diào)用類，常常采用XML存儲數(shù)據(jù)，并基于SOAP與Web Server交互。兩者的優(yōu)劣勢也很明顯，前者較XML封裝方式，數(shù)據(jù)量小，傳輸速度快，后者因為XML的臃腫速度上來說是它的劣勢,不過它的安全性以及開發(fā)速度占有明顯得優(yōu)勢。
如果認真看圖1中對各層的描述，不難看出，里面提到了工廠以及構造器，它是來自于設計模式中的一種思想。其中業(yè)務邏輯層的業(yè)務規(guī)則層、實體層就是運用設計模式的思想來實現(xiàn)的。
2. 設計模式思想的應用
2.1設計模式思想概述
設計模式思想引入企業(yè)級數(shù)據(jù)庫系統(tǒng)開發(fā)，與傳統(tǒng)的開發(fā)模式可謂是一場革命.設計模式之于面向?qū)ο蟮脑O計與開發(fā)的作用就有如數(shù)據(jù)結構之于面向過程開發(fā)的作用一般，其重要性不言而喻。當然學習設計模式的過程也是痛苦的，對于GoF的23種設計模式要一一學懂它，無疑是非常痛苦的。
面向?qū)ο笙到y(tǒng)的設計與分析實際上就是追求的兩點：一是高內(nèi)聚，一是低耦合。這也是我們軟件設計所要追求的，無論是ＯＯ設計中的封裝、繼承、多態(tài)，還是我們的設計模式的原則和實例，都是主要為了追求這兩點。有人說，我們的系統(tǒng)小，使用設計模式會束縛我們的實現(xiàn)，其實不然，就如K_Eckel在他所寫的《設計模式精解》一書中提到的：設計模式體現(xiàn)的是一種思想，而思想是指導行為的一切，理解和掌握了設計模式，并不是說記住GoF的23種設計模式的設計場景以及解決方案，而實際接受的是一種軟件設計思想的熏陶和洗禮，等設計模式的思想真正融入到你的思想中后，你就會不自覺得去采用設計模式的思想去設計你的系統(tǒng)，這才是最重要的。因此我并不想重復地去講述這23種設計模式，更不會拘泥于其中的任何一種，我只是根據(jù)我的經(jīng)驗和對設計模式的思想的理解，來實現(xiàn)我的業(yè)務邏輯層的設計。
我們在面向?qū)ο蟮脑O計中常常會遇到一些問題，比如說為了提高程序的高內(nèi)聚低耦合，我們通常會抽象出一些類的公共接口以形成抽象基類，這樣我們可以為它派生很多個子類,通過申明一個抽象基類的但被實例化為指向派生類的對象，以達到多態(tài)的目的。然而當業(yè)務復雜并產(chǎn)生了大量的派生類時，程序員就得記住每一個派生類的名字然后New出一個指向它的指針。這就給編寫程序和維護代碼帶來了很大的困難，這種情況下我們?nèi)绻罂蛻舳藗魅胍粋€名稱，我們用一個switch根據(jù)傳入的名稱來New一個子類，這就實現(xiàn)了中間層的封裝。還有比如我的一個數(shù)據(jù)庫系統(tǒng)中，有幾百個表/視圖等對象，要對它們進行訪問，如果只用面向?qū)ο蟮乃枷肴ゲ僮魉鼈儯覀冃枰堰@些數(shù)據(jù)庫對象都抽象為類，封裝它們自己的屬性和方法，這樣的工作量無疑是非常巨大的。于是我利用設計模式的思想動態(tài)地分類抽象它們，也就是說，在訪問它們之前，才產(chǎn)生具有實體意義的類。我們可以將幾十個、幾百個屬性、方法類同的數(shù)據(jù)庫表做成一個Template Class,這樣的封裝方式使得代碼量減少到原來的幾十甚至幾百分之一，而且它最大的好處是脫離了數(shù)據(jù)庫… …等等在面向?qū)ο笤O計中出現(xiàn)的問題我們大都可以用設計模式的思想去解決它，就如我們在c程序中遇到一些比較麻煩的功能時，就會想到用數(shù)據(jù)結構中的一些算法去解決它一樣。
2.2數(shù)據(jù)庫應用中設計模式的抽象
說了這么多，我就舉一個例子來說明如何在三層架構部署的企業(yè)級數(shù)據(jù)庫應用系統(tǒng)中如何使用設計模式：
數(shù)據(jù)庫系統(tǒng)中我們最關心的就是如何操作數(shù)據(jù)庫中的那些對象，我們可以將數(shù)據(jù)庫中的對象看作是用來生產(chǎn)某一種產(chǎn)品的模具，每一種類型的對象就是一種模具,比如表、視圖、存儲過程，我們可以將它們當作是三種模具，當然你可以根據(jù)業(yè)務及數(shù)據(jù)庫化分的更細一點，比如單表模具，主從表模具，視圖模具、存儲過程模具、數(shù)據(jù)庫函數(shù)模具等等，不夠的你可以去繼續(xù)擴展;假使我們現(xiàn)在有一個工廠,它有好多個車間，每個車間只能夠使用一種模具來生產(chǎn)產(chǎn)品,我們可以分別給它們起名字叫表車間、視圖車間、存儲過程車間等。當用戶想要往USER表中插入一條記錄的時候，我們可以說成是在工廠要在表車間使用表模具生產(chǎn)出一個叫做USER的產(chǎn)品,然后產(chǎn)品進行加工的過程。那生產(chǎn)并加工這個產(chǎn)品過程到底是怎么樣的呢？這里我說明一下工廠、車間、模具、產(chǎn)品它們各自的功能以及在一個產(chǎn)品在產(chǎn)生和加工過程中所處的環(huán)節(jié)，事實上根據(jù)它們的名字也不難理解。
工廠：它要存貯下所有的產(chǎn)品名和車間名以及產(chǎn)品名與車間的多對一關系，用戶需要知道自己要生產(chǎn)的產(chǎn)品名字是什么，工廠根據(jù)產(chǎn)品名來判斷送交給哪個車間去處理.
車間：車間使用它擁有的模具來產(chǎn)生一個具體產(chǎn)品
模具：模具產(chǎn)生一個產(chǎn)品對象
產(chǎn)品：進行自加工(插入、刪除、修改、查詢等)
那么，現(xiàn)在我們來看看當用戶通過界面層的交互，想對表USER插入一條記錄的過程：事實上用戶并不知道它現(xiàn)在操作表叫做USER,而界面層上的對象則必須知道當前操作界面所對應數(shù)據(jù)庫表的名字，有了這個已知條件,界面層調(diào)用業(yè)務接口層的提供的獲取表信息函數(shù)接口【例如：DataSet GetTabInfo(string _tabname）;//得到當前表的信息】，接口產(chǎn)生一個工廠，工廠就判斷這個USER屬于哪個車間生產(chǎn)，將USER轉(zhuǎn)交給表車間，表車間產(chǎn)生一個表模具對象，并生產(chǎn)出一個名叫USER的產(chǎn)品對象,產(chǎn)品對象調(diào)用自己的獲取信息函數(shù)【例如：DataSet GetTabInfo(string _tabname）;//得到當前表的信息，并記錄到產(chǎn)品對象屬性中,實際上這個GetTabInfo過程調(diào)用了數(shù)據(jù)訪問層提供的花取字段信息接口】,對本身做了一次加工，也就是說此時USER這個產(chǎn)品已經(jīng)擁有了USER表的信息(字段、主鍵等),然后返回到業(yè)務接口層，業(yè)務接口層將這個具體的USER產(chǎn)品返回給界面層，界面層得到產(chǎn)品后，將數(shù)據(jù)填充到產(chǎn)品的屬性(行和列)中，實際上就是增加一行給字段賦值的過程,然后再調(diào)用業(yè)務接口提供的插入數(shù)據(jù)接口【例如:InsertData(DataSet _tabinfo);】,同樣的，接口產(chǎn)生工廠，工廠找到車間，重新構造產(chǎn)品，產(chǎn)品對象對本身做插入操作,返回。這就是一個完整的操作過程。
當我真正地了解了GoF的《設計模式：可復用面向?qū)ο筌浖幕A》中的思想后，我突然發(fā)現(xiàn)真正如K_Eckel所說，經(jīng)過了一場軟件設計思想的洗禮，做系統(tǒng)設計時的思想發(fā)生了質(zhì)的變化，封裝、復用、多態(tài)、抽象……
3.三層架構與設計模式在Web應用系統(tǒng)中的應用
3.1用c#描述系統(tǒng)架構設計
3.1.1在.net中創(chuàng)建工程
1) 首先打開Microsoft Visual Stdio .Net 2003,新建一個C#項目asp.net Web應用程序，如圖2所示:
圖2
2) 在新生成的解決方案中加入以下類庫：
GlobalDataTypeLayer:公用參數(shù)層
BusinessLayer:業(yè)務邏輯層（可以將里面的四層全部分開，建成類庫）
DataAccessLayer:數(shù)據(jù)訪問層，為了更好的擴展，我在代碼表現(xiàn)形式上只將該層從業(yè)務邏輯層分離出來
界面規(guī)則層可直接置于asp.net項目中，因為它是界面外觀層的基類，在一個命名空間中使用比較方便。各層之間互相的引用聯(lián)系是這樣的，首先要將GlobalDataTypeLayer命名空間在其它各層全部引用，UserRoleLayer命名空間中再引用BusinessLayer,BusinessLayer再引用DataAccessLayer。引用事例圖如圖3所示:
圖3
3.1.2應用于系統(tǒng)層次結構調(diào)用過程以及類的代碼實現(xiàn)
3.1.2.1界面表示層類圖(如圖4)
圖4
圖2展示的是用戶界面表示層的類圖結構，圖中顯示了共三個類，WebForm Class與PrintControl Class都屬于界面外觀層。
WebForm Class這不僅僅表示一個類，而表示一批類，因為一般情況下與用戶交流的類的屬性及操作都大同小異，我們可以從一個基類中派生，以便于編程和管理。當然如果有一些類差別比較大，可以重新概造相應的基類，重新派生，界面層的擴展可以很靈活地通過增加基類來實現(xiàn)。
PrintControl Class : 打印控制類，主要以客戶端腳本來實現(xiàn)，不與服務器進行數(shù)據(jù)交互，打印預覽之前，打印數(shù)據(jù)應由WebForm類提交給PrintControl。
PageBase Class 這個類屬于界面規(guī)則層，它是WebForm的基類，事實上界面外觀與界面規(guī)則可以放在一個命名空間中，它可以是一個類，也可以是多個類，業(yè)務的復雜程度也決定了PageBase Class的擴展，根據(jù)不同的需求可以構造相應的WebForm基類來滿足業(yè)務需求。實現(xiàn)基類部分代碼見附錄A.
3.1.2.2業(yè)務邏輯層類圖(如圖5)
圖5
圖5展示了復雜的業(yè)務邏輯層調(diào)用過程,其中主要展示的類有六個類，不包含派生的子類。
ParamData Class 公用參數(shù)類，這個類事實上并不屬于三層架構中的任何層，我單獨將其定義為公用參數(shù)層，它與三層架構中的任何一個類都息息相關,實現(xiàn)代碼見附錄A
InterfaceImpl Class 是業(yè)務邏輯層向界面表示層提供的接口類，數(shù)據(jù)由界面規(guī)則層封裝傳入，對外接口函數(shù)根據(jù)業(yè)務需求可以增加。該類的所有函數(shù)實現(xiàn)基本都很類似，我這里列出數(shù)據(jù)庫連接和一個SaveData的代碼實例,見附錄A
ClassBuilderFactory Class 工廠類，它的作用是根據(jù)接口類傳入的數(shù)據(jù)找到對應的生產(chǎn)構造部件(ClassBuilder),這里很重要的是包含了一個簡單的map，該結構在連接數(shù)據(jù)庫里進行實例化，代碼實現(xiàn)見附錄A
ClassBuilder Class 這是構造部件的抽象基類，其下可以根據(jù)業(yè)務的需求擴展很多的構件器，可以用工廠的模式理解其為構件車間，我這里派生的構件器有：
TableClassBuilder:實體表構件器
ViewClassBuilder:視圖構件器
ProcedureClassBuilder:存儲過程構件器
OtherClassBuilder:其它構件器
基類和實體表構件器的代碼實現(xiàn)見附錄A
EntityData Class 這是實體類的抽象基類，其下也可以根據(jù)業(yè)務的需求擴展派生實體，前面我提到過我們的構件器與實體類是一一對應的，一個構件車間只能夠生產(chǎn)一類產(chǎn)品。那么對應的派生實體就有：
TableEntityData:表實體
ViewEntityData:視圖實體
ProcedureEntityData:存儲過程實體
OtherClassEntityData:其它實體(這個實體的自我加工可以靈活定義)
實體抽象基類及表實體的代碼實現(xiàn)見附錄A
DataAccess Class 是數(shù)據(jù)訪問層的數(shù)據(jù)訪問類，這里才真正實現(xiàn)了數(shù)據(jù)庫連接，數(shù)據(jù)庫讀寫等，將用戶的數(shù)據(jù)構造成sql語句與數(shù)據(jù)庫交互。如果想在整個系統(tǒng)中兼容各種數(shù)據(jù)庫，那么可以將它抽象為數(shù)據(jù)訪問的抽象基類，可以去派生OracleDataAccess,SqlServerDataAccess,AccessDataAccess等等，它們的屬性和方法基本上都是相同的，只是具體方法中的實現(xiàn)有所不同而已，訪問Oracle部分實例代碼見附錄A。
在實例化并填充工廠MAP的時候用XML存儲構件的產(chǎn)品名與產(chǎn)品類型名的多對一關系，XML結構見附錄A。
3.1.2.3 數(shù)據(jù)庫層
數(shù)據(jù)庫層指的主要是系統(tǒng)采用的數(shù)據(jù)庫管理系統(tǒng)(DBMS),在整套企業(yè)級數(shù)據(jù)庫應用系統(tǒng)中，它是最重要的一環(huán)，其中主要的對象有表、視圖、存儲過程、函數(shù)、觸發(fā)器等，數(shù)據(jù)的許多處理都應該由數(shù)據(jù)庫本身去完成，例如將復雜的查詢或者數(shù)據(jù)寫入，都封裝為存儲過程和函數(shù)，將數(shù)據(jù)寫入前后要進行的附加操作用觸發(fā)器實現(xiàn)等等。對于表的創(chuàng)建一般應以數(shù)據(jù)庫原理的第三范式規(guī)范來創(chuàng)建,允許一定的冗余。表及視圖的創(chuàng)建規(guī)范直接影響到代碼編寫的難易度。
到這里，關于三層架構與設計模式思想部署企業(yè)級數(shù)據(jù)庫應用系統(tǒng)開發(fā)應趨于完整了，我想主要向大家展示的實際上就是一種程序設計的思想，不管是三層架構還是設計模式，它們都是軟件工程面向?qū)ο笏枷氲耐耆w現(xiàn)，目前，我們國家軟件業(yè)相對來說是很落后的，關鍵的問題是軟件企業(yè)的急功近利和程序員思想還停留在結構化思想上，不能說你在程序中用的是類就說你的思想是面向?qū)ο螅膊皇钦f你會使用java編寫程序，就說自己懂得面向?qū)ο螅Ｍ液痛蠹夷芤黄疬M步，直正理解面向?qū)ο蟆?/span>
參 考 文 獻
1 GoF,設計模式：可復用面向?qū)ο筌浖幕A
2 k_Eckel,設計模式精解