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