主題：建立可維護、可擴展的站點，開發高效率、高伸縮性的應用程序、創建N層分佈式應用程序、實現跨平臺、跨Internet的應用集成，是擺在無數開發者面前的任務。傳統開發方式及技術面臨了困難。
.Net Framework推出的許多新技術爲上述任務的實現提供了相對簡單的解決方案。其中，基於SOAP的Web Service在處理分佈式應用時具有比傳統的DCOM/CORBA明顯的優點，結合基於Web的ASP.NET頁面開發技術和SQL Server數據存儲技術（或Xml文檔），在.Net下開發N層應用程序也不再困難。
一、分佈式處理概述
分佈式處理是將應用程序邏輯分佈到2臺或者更多臺計算機上，在物理上或邏輯上分離的單元中。這一概念並不是新生事物，在大型工程已經得到廣泛使用。只不過，Internet的出現爲分佈式處理賦予了新的特徵，Internet內部連接的特性可以讓成百上千的計算機爲一個任務工作，使得在更大規模上實施分佈式處理成爲可能，並跨越了傳統的B/S（客戶機/服務器）模型。
分佈式處理思想經歷了很長的過程，不同IT時代的開發人員、各級供應商做了大量的工作，使得支持分佈式處理的協議極爲豐富。
1、 DCOM/CORBA
在.Net Framework之前，基於組件的分佈式計算的主要協議是CORBA(Common Object Request Broker Architecture,通用對象請求代理結構)，它來自Object Management Group(對象管理組)，還有Microsoft的DCOM（Distributed Component Object Model，分佈式組件對象模型）。
DCOM是面向連接的。DCOM客戶機持有對DCOM服務器的連接。這種連接方式導致了技術問題存在。例如，客戶機可能持有引用信息，只有在用戶單擊按鈕時生成調用。時間一長，服務器就會因等待客戶機的請求而空閒。當客戶機崩潰而無法請求服務器時，就會產生嚴重的後果。另外，在Internet上，DCOM或者CORBA服務器由數千臺客戶機使用，由於每一臺客戶機都有一個與服務器的連接，對於很少使用服務器或者根本不再使用服務器的客戶機，應該保護寶貴的服務器資源。
儘管DCOM有辦法處理這些問題，但是增加了許多複雜性，這也是Web服務試圖解決的問題之一。
2、Web 服務
隨着Microsoft .Net Framewwork的推出，實現分佈式處理有了新的技術，即Web Service（Web服務）。Web服務能夠爲另一個應用程序而不僅僅是瀏覽器提供數據，並通過外置數據以允許其他的客戶機使用在同樣的端口和傳輸層都起作用的標準協議（如HTTP）來執行操作。
二、Web Service-.Net Framework下的分佈式處理技術
在.Net Framework中，Web服務指是以獨立於平臺的方式，通過標準的Web協議，可以由程序訪問的應用程序邏輯單元。
.Net Framework的開發者們將Web服務定位於基於開放的標準，能夠用於任何平臺。使它擁有作爲跨平臺和跨供應商的集成技術的潛力。實現了Web服務和Web服務構架後，用戶就可以利用Internet上許多現有技術。Web服務成功的關鍵在於它基於開放的標準，諸如Microsoft、IBM和Sun等主要供應商都支持這些標準。
1、DCOM/CORBA面臨困難之解決方案--Web服務
DCOM和CORBA在使用運行於相同平臺的軟件和緊密管理的局域網創建企業應用程序時非常優秀。但是，他們在創建跨平臺 、跨Internet、適應Internet的可伸縮性的應用程序時力不從心。他們不是爲完成這些目標而設計的。
大多數公司面臨的現實情況是他們擁有來自多個供應商的多種平臺。運行於不同平臺上的應用程序系統間通信困難。在與商務夥伴合作時，基於傳統分佈式的架構合作困難。
DCOM和CORBA的問題是用戶基本上要依賴一個供應商。如果要使用DCOM，就必須使用Microsoft Windows來運行服務器和客戶機。儘管有其他平臺上的DCOM實現方式，但是他們未被廣泛採納。雖然CORBA是由多個供應商實現的規範，互操作性仍只能以簡單的方式完成，至於DCOM和CORBA間的集成就不必說了。
從技術方面看，Web服務試圖解決使用諸如CORBA和DCOM這樣緊密捆綁的技術時遇到的問題。這些問題包括如何通過防火牆，協議的複雜性，異類平臺的集成等。
2、Web服務在分佈式處理中的應用
Web服務是一種優秀的分佈式處理技術。
下圖演示了在.Net Framework下進行分佈式處理的一般情形。作爲客戶端應用程序可以是傳統的Windows Form應用程序、基於Web的Asp.net應用程序、蜂窩式移動應用程序等，還可以是另外的Web服務程序。這些客戶端應用程序構成N層模型中的表示層（圖中左列）用於數據顯示。中間列是中間層，處理商務邏輯；右列是數據層，處理數據存儲。
![188368.gif]()
隨着一個基於xml的名爲簡單對象訪問協議SOAP（Simple Object Access Protocol）的不斷標準化，web服務正成爲一個可以和其他服務器和應用程序交互、可行的方法。
3、N層模型下客戶機消費Web服務
下圖演示了客戶機消費Web服務的情形。客戶機可以是一個Web應用程序、另一個Web服務、諸如Microsoft Word的字處理程序等。
![188372.gif]()
Web服務的消費者調用名爲Method()的Web服務上的方法。實際調用向下層傳播，作爲Soap消息通過網絡，並向上層傳播到Web服務。Web服務執行並響應（如果有的話）。
實現Web服務與客戶機之間的雙向通知或者發佈/訂閱功能是可能的，但是必須手工完成。客戶機可以實現自己的Web服務並在對服務器的調用中傳遞該Web服務的引用。服務器可以保存引用，然後回調給客戶機。
三、基於.Net Framework的N層構架設計
面向對象的、基於模塊化的組件設計需要能夠方便地修改應用程序的各個部分。完成這一目標的一種好方法就是在層上工作，將一個應用程序的主要功能分離到不同的層或者級中。.Net Framework爲創建可維護、可擴展的層模式提供了豐富的支持，使得N層夠架取代傳統的客戶機/服務器模式而與Internet緊密結合。
1、分層模型
從本質上講，層代表了一個應用程序主要的功能。一般地，我們將應用程序功能分爲三個方面，對應3層架構模式。它們是數據層（data layer）、商務層（business layer）和表示層（presentation layer）。
數據層：包含數據存儲和與它交互的組件或服務。這些組件和服務在功能上和中間層相互獨立（儘管在物理上不必一定相互獨立--它們可以在同一臺服務器上）。
中間層：包括一個或者多個組件服務，它們應用商務規則、實現應用程序邏輯並完成應用程序運行所需要的數據處理。作爲這個過程的一部分，中間層負責處理來自數據存儲或者發送給數據存儲的數據。
表示層：從中間層獲得信息並顯示給用戶。該層同時也負責和用戶進行交互，比較返回的信息並將信息回送給中間層進行處理。
可見，數據層從數據庫中獲得較爲原始的數據，商務層把數據轉換成符合商務規則的有意義的信息，表示層把信息轉換成對於用戶有意義的內容。
這種分層設計方式很有用，因爲每一層都可以獨立地修改。我們可以修改商務層，不斷地從數據層接受相同的數據，並把這些數據傳遞到表示層，而不用擔心出現歧義。我們也可以修改表示層，使得對於站點外觀的修改不必改動下面的商務層邏輯。
2、常用的N層模型設計
已經知道，一個N層應用程序中的層不是由運行應用程序的物理結構（硬件）定義的。層是應用程序運行的一個邏輯方面的功能，並定義應用程序將執行的不同的任務階段。這裏的N層設計與經典的客戶機/服務器架構截然不同。
1）、設計一個簡單的3層
最簡單的N層模型就是3層。這裏，我們已經有一個被網絡分隔開的服務器和客戶機。服務器中含有數據存儲和組成數據層的數據訪問組件，已經組成中間層的商務邏輯。客戶機作爲表示層只需要給應用程序提供界面即可。
![188373.gif]()
在這個最簡單的情況中我們或許有一個關係數據庫或者一組訪問數據的組件或者存儲過程。然後我們應當有一個訪問組件或者存儲過程的asp.net頁面來提取信息，處理和格式化信息使之適合於特定的客戶機，然後通過網絡將信息傳送給客戶機。客戶機所要做的事情就是顯示信息、收集用戶的輸入和將信息回送給中間層。
2）、設計一個更接近現實的3層
然而前面的示例只是非常小的應用程序的一般情況，現實世界中很難碰到。數據存儲通常位於專門選擇和經過專門設置的硬件上。它也許是在運行SQL Server的基於Windows的一組服務器上，但是也可能是運行非Windows平臺或Oracle或者其他的數據庫服務器上。
![188374.gif]()
在這種情況下，數據層和中間層之間的分離就更加顯而易見--它們之間通過網絡連接。並且，商務邏輯被限制在執行所有中間層數據處理的服務器上。
3）、設計N層
很明顯，上面的情況都假定了兩件事：一是客戶機爲一個低端設備（因此不參與應用程序中所需的實際數據處理）；另外就是隻有一組商務規則。
然而，這些假設並不符合實際的應用程序。例如，我們通常期望商務規則在其他某個地方而非在中間層中。在提取數據過程的前期實現某個商務邏輯比較恰當，當然我們也可以在訪問數據存儲的組件中實現商務邏輯。這個商務邏輯"包"因此能和數據存儲在同一個服務器上，或者甚至（在一個分組的環境中）在另外一箇中間路由服務器上。
另外，爲了充分利用"胖客戶機"的一些性能，以便減少網絡負載和因訪問路徑循環而導致的遲滯，我們可以將一些商務邏輯放在客戶機上。
下圖就顯示了這種變化，其中商務邏輯已經從中間層剝離並位於數據服務器或者客戶機上。
![188375.gif]()
可見，這種模式沒有中間存儲並且幾乎不需要中間數據處理，所以效率更高。
4）、設計一個更加現實的N層
一般地，我們使用一個或者多個分離的服務器來維持我們正在使用的數據存儲，這時，商務邏輯的分佈更爲分散。下圖顯示了由兩個網絡分離的三個機器。可以看出，現在的商務邏輯被分爲三個區：一些將和數據存儲運行在同一臺服務器上，另一些將在中間層服務器上運行，還有一些將在客戶機上運行。
![188376.gif]()
由此可以看到，準確定義各個層並不容易。"中間層"的真正意思是商務邏輯本身，並且，商務邏輯的不同元素可以無可非議地存在於不同的服務器中。
3、.Net Framework下的層間(遠程)傳輸對象及技術
.Net Framework實現了許多新的技術以支持多層分佈式處理，它提供了豐富的類庫、對象及方法使得在不同層(物理上分離或僅僅是邏輯上分離)間的數據傳輸更爲簡單。
1）、支持遠程數據傳送的對象：
l ADO.NET DataSet對象
l ADO.NET DataTable對象
l XmlDocument對象
l XmlDataDocument對象
2）、支持遠程數據傳送的類/方法：
l Serialization類
Serialization類描述了一個將數據轉換爲一種能複製到另一個過程的格式的對象的過程。前面提及的可遠程傳輸的對象具有串行化整個內容的能力，以便它可以通過一個通道來傳送。這個通道可以直接通過TCP/IP，或者通過HTTP。當然，它們也可以在另一端解除串行化，因此客戶機就得到一個原對象的完整副本。
l System.Runtime.Remoting類
System.Runtime.Remoting命名空間提供的對象可用來爲對象創建代理以實現遠程數據傳送。在這種情形下，對象保留在服務器上，並且客戶機只收到一個代理對象的引用。這個代理對象表示原來的基於服務器的對象（這就是我們怎樣遠程使用一個DataReader的方法），示意如下圖：
![188377.gif]()
對於客戶機，這個代理提供了與原始對象相同的方法和屬性。然而，當客戶機與代理對象相互作用時，調用被自動串行化，並通過通道（網絡）傳送給服務器上的對象。然後，任何響應和結果通過通道被傳送回客戶機。
這兩個遠程技術都允許客戶機使用原來在服務器上創建的對象。我們能夠串行化一個DataSet對象或者Xml文檔，同時我們也能串行化其它的如集合這樣的對象--比如一個哈希表(Hashtable)或數組(Array)。
4、N層模型中的數據處理及對象選擇
首先需要考慮的是希望從數據存儲中提取出來的數據做些什麼？這個問題的答案對我們所使用對象的基本選擇的影響將比其他任何事情都要大，甚至在某種程度上定義了我們希望完成任務的性能的種類。
1）、只用於顯示的數據
如果只是想以一種固定格式爲終端用戶顯示數據的話，一般來說根本就沒有必要遠程傳輸數據。我們沒有必要在線上將所有的數據傳送給客戶機--我們只能傳給它們客戶設備能接受的任何格式的最終顯示信息。
在這種情形中，"Reader"對象提供了一種只讀的、僅向前的理想且性能最優的技術。當與能實現服務器端數據綁定的服務器控件一起使用時，我們可以獲得一個顯示數據的高效方法。
2）、需要遠程傳輸的數據
然而，如果我們需要遠程傳輸數據的話則存在一個問題。這些快速而高效的"Reader"對象只在作爲一個引用時才能被遠程傳輸。將一個DataReader作爲引用傳送給一個客戶機時，DataReader仍還在服務器上，不過客戶機的應用程序也可以使用它。在這種情況下，我們實際上並沒有遠程傳輸數據，而是使用了一個遠程傳輸對象。在很多情況下都存在這種情況。
要實現數據的遠程傳送，應該將數據寄存到一個能夠存儲（或保持）數據的對象中。並允許代碼不需進入數據存儲的額外行程就可以根據需要提取數據，並且多次讀取。在ADO.NET中，這個對象就是DataSet對象（或者DataTable對象）。當使用xml時，也有幾個對象供選擇。我們能夠遠程傳輸XmlDocument和XmlDataDocument對象。這兩個對象都有保持內容的能力，並且可以在一個應用程序的層之間進行傳送。
四、N層分佈式數據處理架構模型
要進一步理解怎樣在應用程序中劃分不同的層，需要確定數據如何顯示以及是否需要更新數據和向服務器及時返回更新。
1、全部在服務器上完成顯示
在客戶機上顯示數據，最常見的情形是在一組或者多組服務器上執行所有的數據處理。數據層和中間層限於服務器，客戶機只提供顯示接口。對於一個web瀏覽器來說，通常的格式爲html，對於一個蜂窩式電話或類似設備來說，可能是以wml格式表示，等等。
下圖使用一個存儲過程或SQL語句來提取所需要的數據，然後用asp.net進行處理，或者執行一個web服務。另外，這裏也用xml片段的形式從數據存儲中提取數據，然後對數據進行處理並提供給客戶機。
![188388.gif]()
如果以xml文檔形式存儲數據，或者以這樣一種格式存儲數據：數據作爲xml外置數據層，那麼我們就有一些其他的選擇。
下圖顯示了怎樣提取和處理xml數據以便傳送給客戶機使用。此外，數據的提取其實就是藉助一個"Reader"對象，並且可以使用不同的技術來處理數據並將數據提供給客戶機。
![188389.gif]()
2、擴展中間層
雖然數據的提取和處理經常在一個對象裏發生，比如一個Asp.Net頁面，但是爲了有效利用由於使用基於組件的設計而提供的好處，通常需要提供更爲精細的架構。我們應該有在顯示數據或者將其傳送給客戶機之前應用於數據的商務規則。換句話說，它可能是因爲安全的原因，也可能是爲了實現分佈式處理，或者只是提供可重用性和使應用程序的維護更加容易。
例如，應該有訪問一個數據存儲並提取一系列消費者的多個頁面。通過在一個獨立於asp.net頁面或其他提供數據給客戶機的對象的組件中建立這個過程，我們能夠提供一個提取數據的層。然後，我們在將來需要在某些方面改變數據存儲或者數據結構，或者改變訪問它的規則，我們只要用一個新的版本替換組件即可。
只要組件的接口仍然未變，所有使用這個接口的應用程序將看到來自組件的相同輸出並和以前一樣繼續運行。然而，組件在內部用來提取和處理來自數據存儲的數據的方法可以根據需要進行相應修改。下圖示意了這種架構。
![188369.gif]()
顯然，該過程可以使用多個組件。如果數據的提取相當複雜，或者同一數據運用在多個地方的話，進一步分解數據處理（分解爲更多組件層）就很有意義。例如，可用一個組件將數據當作一系列包含所有必須列的行（以關鍵字順序排列），這個組件就可以成爲其他以不同順序存儲數據的組件，或者僅外置數據的某些列的組件的數據源。
3、移動數據處理到客戶機
一般地，要獲得發送給客戶機的數據，我們將利用客戶端腳本（JavaScript或 VBScript以及 WMLScript）、用Java或者一個特定平臺的語言書寫的客戶端組件，或者用諸如Visual Basic 6.0、C++、Delphi等語言書寫的客戶端可執行程序等等。當然，所有我們需要的功能都是.Net Framework的一部分。（用戶可通過下載和安裝可重新分配的Framework（大約5MB）在客戶機上使用Framework）。
因此，下面的示意圖顯示了一些用於實現獲得發送給客戶機的數據並在客戶機上進行處理的方法。
![188370.gif]()
4、將更新回送給服務器
在許多情況下，如果我們的要求就是以一種儘可能快速和高效的方式獲得發送給客戶機的依據，那麼，上面的示例能很好地完成任務。然而，許多應用程序要求客戶機將數據回送以更新數據存儲等操作時，就需要尋找更合理的模式。
至少有三種方法用於向服務器端回送數據。一是回送Html表單和查詢字符串(實現方式與以前的ASP類似)；另一是客戶端組件(例如IE5及以上版本的XMLHTTP組件)；還有就是客戶端可執行的Windows表單應用程序和服務等。
因此，應該有這樣一種情況：客戶機僅僅要求我們發送一些數據，並且我們讓客戶機完成所有的數據處理。也就是說，客戶機充當某種類型的服務，它將應用程序的數據作爲自己的源數據來使用，然後在它的客戶機已經處理數據後將更改提交回來。
一旦客戶端完成了數據更新，或者已經收集了用戶輸入的新數據，客戶機應用程序就以一種合適的格式打包數據（或者用正確的技術整理數據），並將它提交給服務器進行處理和存儲。
下圖顯示了利用"胖客戶機"來實現這種架構的方法，其中數據在客戶機上進行處理，然後經整理後返回給服務器來更新原始的數據存儲。
![188371.gif]()
仍然地，這不是一個包含所有可能性的圖表。回送數據的方法或許和發送數據的方法沒有什麼聯繫。你應該根據應用程序的實際需求設計合適的模型。
五、結束語
建立可維護、可擴展的站點，開發高效率、高伸縮性的應用程序、實現跨平臺、跨Internet的應用集成、創建N層分佈式應用程序是擺在無數開發者面前的任務。傳統開發方式及技術面臨了困難。
.Net Framework推出的許多新技術爲這些任務的實現提供了相對簡單的解決方案。其中，基於SOAP的Web Service在處理分佈式應用時具有比傳統的DCOM/CORBA明顯的優點，結合基於Web的ASP.NET頁面開發技術和SQLServer數據存儲技術（或Xml文檔），在.Net下開發N層應用程序也不再困難。
要很好地完成以上任務，你需要根據實際情況設計合理的應用程序架構模型。本文正是爲了在這方面爲你提供參考。
參考資料：《ASP.NET Web服務高級編程》、《.Net Framework技術內幕》、《ASP.NET分佈式數據應用程序高級編程》、MSDN在線
一、分佈式處理概述
分佈式處理是將應用程序邏輯分佈到2臺或者更多臺計算機上，在物理上或邏輯上分離的單元中。這一概念並不是新生事物，在大型工程已經得到廣泛使用。只不過，Internet的出現爲分佈式處理賦予了新的特徵，Internet內部連接的特性可以讓成百上千的計算機爲一個任務工作，使得在更大規模上實施分佈式處理成爲可能，並跨越了傳統的B/S（客戶機/服務器）模型。
分佈式處理思想經歷了很長的過程，不同IT時代的開發人員、各級供應商做了大量的工作，使得支持分佈式處理的協議極爲豐富。
1、 DCOM/CORBA
在.Net Framework之前，基於組件的分佈式計算的主要協議是CORBA(Common Object Request Broker Architecture,通用對象請求代理結構)，它來自Object Management Group(對象管理組)，還有Microsoft的DCOM（Distributed Component Object Model，分佈式組件對象模型）。
DCOM是面向連接的。DCOM客戶機持有對DCOM服務器的連接。這種連接方式導致了技術問題存在。例如，客戶機可能持有引用信息，只有在用戶單擊按鈕時生成調用。時間一長，服務器就會因等待客戶機的請求而空閒。當客戶機崩潰而無法請求服務器時，就會產生嚴重的後果。另外，在Internet上，DCOM或者CORBA服務器由數千臺客戶機使用，由於每一臺客戶機都有一個與服務器的連接，對於很少使用服務器或者根本不再使用服務器的客戶機，應該保護寶貴的服務器資源。
儘管DCOM有辦法處理這些問題，但是增加了許多複雜性，這也是Web服務試圖解決的問題之一。
2、Web 服務
隨着Microsoft .Net Framewwork的推出，實現分佈式處理有了新的技術，即Web Service（Web服務）。Web服務能夠爲另一個應用程序而不僅僅是瀏覽器提供數據，並通過外置數據以允許其他的客戶機使用在同樣的端口和傳輸層都起作用的標準協議（如HTTP）來執行操作。
二、Web Service-.Net Framework下的分佈式處理技術
在.Net Framework中，Web服務指是以獨立於平臺的方式，通過標準的Web協議，可以由程序訪問的應用程序邏輯單元。
.Net Framework的開發者們將Web服務定位於基於開放的標準，能夠用於任何平臺。使它擁有作爲跨平臺和跨供應商的集成技術的潛力。實現了Web服務和Web服務構架後，用戶就可以利用Internet上許多現有技術。Web服務成功的關鍵在於它基於開放的標準，諸如Microsoft、IBM和Sun等主要供應商都支持這些標準。
1、DCOM/CORBA面臨困難之解決方案--Web服務
DCOM和CORBA在使用運行於相同平臺的軟件和緊密管理的局域網創建企業應用程序時非常優秀。但是，他們在創建跨平臺 、跨Internet、適應Internet的可伸縮性的應用程序時力不從心。他們不是爲完成這些目標而設計的。
大多數公司面臨的現實情況是他們擁有來自多個供應商的多種平臺。運行於不同平臺上的應用程序系統間通信困難。在與商務夥伴合作時，基於傳統分佈式的架構合作困難。
DCOM和CORBA的問題是用戶基本上要依賴一個供應商。如果要使用DCOM，就必須使用Microsoft Windows來運行服務器和客戶機。儘管有其他平臺上的DCOM實現方式，但是他們未被廣泛採納。雖然CORBA是由多個供應商實現的規範，互操作性仍只能以簡單的方式完成，至於DCOM和CORBA間的集成就不必說了。
從技術方面看，Web服務試圖解決使用諸如CORBA和DCOM這樣緊密捆綁的技術時遇到的問題。這些問題包括如何通過防火牆，協議的複雜性，異類平臺的集成等。
2、Web服務在分佈式處理中的應用
Web服務是一種優秀的分佈式處理技術。
下圖演示了在.Net Framework下進行分佈式處理的一般情形。作爲客戶端應用程序可以是傳統的Windows Form應用程序、基於Web的Asp.net應用程序、蜂窩式移動應用程序等，還可以是另外的Web服務程序。這些客戶端應用程序構成N層模型中的表示層（圖中左列）用於數據顯示。中間列是中間層，處理商務邏輯；右列是數據層，處理數據存儲。
隨着一個基於xml的名爲簡單對象訪問協議SOAP（Simple Object Access Protocol）的不斷標準化，web服務正成爲一個可以和其他服務器和應用程序交互、可行的方法。
3、N層模型下客戶機消費Web服務
下圖演示了客戶機消費Web服務的情形。客戶機可以是一個Web應用程序、另一個Web服務、諸如Microsoft Word的字處理程序等。
Web服務的消費者調用名爲Method()的Web服務上的方法。實際調用向下層傳播，作爲Soap消息通過網絡，並向上層傳播到Web服務。Web服務執行並響應（如果有的話）。
實現Web服務與客戶機之間的雙向通知或者發佈/訂閱功能是可能的，但是必須手工完成。客戶機可以實現自己的Web服務並在對服務器的調用中傳遞該Web服務的引用。服務器可以保存引用，然後回調給客戶機。
三、基於.Net Framework的N層構架設計
面向對象的、基於模塊化的組件設計需要能夠方便地修改應用程序的各個部分。完成這一目標的一種好方法就是在層上工作，將一個應用程序的主要功能分離到不同的層或者級中。.Net Framework爲創建可維護、可擴展的層模式提供了豐富的支持，使得N層夠架取代傳統的客戶機/服務器模式而與Internet緊密結合。
1、分層模型
從本質上講，層代表了一個應用程序主要的功能。一般地，我們將應用程序功能分爲三個方面，對應3層架構模式。它們是數據層（data layer）、商務層（business layer）和表示層（presentation layer）。
數據層：包含數據存儲和與它交互的組件或服務。這些組件和服務在功能上和中間層相互獨立（儘管在物理上不必一定相互獨立--它們可以在同一臺服務器上）。
中間層：包括一個或者多個組件服務，它們應用商務規則、實現應用程序邏輯並完成應用程序運行所需要的數據處理。作爲這個過程的一部分，中間層負責處理來自數據存儲或者發送給數據存儲的數據。
表示層：從中間層獲得信息並顯示給用戶。該層同時也負責和用戶進行交互，比較返回的信息並將信息回送給中間層進行處理。
可見，數據層從數據庫中獲得較爲原始的數據，商務層把數據轉換成符合商務規則的有意義的信息，表示層把信息轉換成對於用戶有意義的內容。
這種分層設計方式很有用，因爲每一層都可以獨立地修改。我們可以修改商務層，不斷地從數據層接受相同的數據，並把這些數據傳遞到表示層，而不用擔心出現歧義。我們也可以修改表示層，使得對於站點外觀的修改不必改動下面的商務層邏輯。
2、常用的N層模型設計
已經知道，一個N層應用程序中的層不是由運行應用程序的物理結構（硬件）定義的。層是應用程序運行的一個邏輯方面的功能，並定義應用程序將執行的不同的任務階段。這裏的N層設計與經典的客戶機/服務器架構截然不同。
1）、設計一個簡單的3層
最簡單的N層模型就是3層。這裏，我們已經有一個被網絡分隔開的服務器和客戶機。服務器中含有數據存儲和組成數據層的數據訪問組件，已經組成中間層的商務邏輯。客戶機作爲表示層只需要給應用程序提供界面即可。
在這個最簡單的情況中我們或許有一個關係數據庫或者一組訪問數據的組件或者存儲過程。然後我們應當有一個訪問組件或者存儲過程的asp.net頁面來提取信息，處理和格式化信息使之適合於特定的客戶機，然後通過網絡將信息傳送給客戶機。客戶機所要做的事情就是顯示信息、收集用戶的輸入和將信息回送給中間層。
2）、設計一個更接近現實的3層
然而前面的示例只是非常小的應用程序的一般情況，現實世界中很難碰到。數據存儲通常位於專門選擇和經過專門設置的硬件上。它也許是在運行SQL Server的基於Windows的一組服務器上，但是也可能是運行非Windows平臺或Oracle或者其他的數據庫服務器上。
在這種情況下，數據層和中間層之間的分離就更加顯而易見--它們之間通過網絡連接。並且，商務邏輯被限制在執行所有中間層數據處理的服務器上。
3）、設計N層
很明顯，上面的情況都假定了兩件事：一是客戶機爲一個低端設備（因此不參與應用程序中所需的實際數據處理）；另外就是隻有一組商務規則。
然而，這些假設並不符合實際的應用程序。例如，我們通常期望商務規則在其他某個地方而非在中間層中。在提取數據過程的前期實現某個商務邏輯比較恰當，當然我們也可以在訪問數據存儲的組件中實現商務邏輯。這個商務邏輯"包"因此能和數據存儲在同一個服務器上，或者甚至（在一個分組的環境中）在另外一箇中間路由服務器上。
另外，爲了充分利用"胖客戶機"的一些性能，以便減少網絡負載和因訪問路徑循環而導致的遲滯，我們可以將一些商務邏輯放在客戶機上。
下圖就顯示了這種變化，其中商務邏輯已經從中間層剝離並位於數據服務器或者客戶機上。
可見，這種模式沒有中間存儲並且幾乎不需要中間數據處理，所以效率更高。
4）、設計一個更加現實的N層
一般地，我們使用一個或者多個分離的服務器來維持我們正在使用的數據存儲，這時，商務邏輯的分佈更爲分散。下圖顯示了由兩個網絡分離的三個機器。可以看出，現在的商務邏輯被分爲三個區：一些將和數據存儲運行在同一臺服務器上，另一些將在中間層服務器上運行，還有一些將在客戶機上運行。
由此可以看到，準確定義各個層並不容易。"中間層"的真正意思是商務邏輯本身，並且，商務邏輯的不同元素可以無可非議地存在於不同的服務器中。
3、.Net Framework下的層間(遠程)傳輸對象及技術
.Net Framework實現了許多新的技術以支持多層分佈式處理，它提供了豐富的類庫、對象及方法使得在不同層(物理上分離或僅僅是邏輯上分離)間的數據傳輸更爲簡單。
1）、支持遠程數據傳送的對象：
l ADO.NET DataSet對象
l ADO.NET DataTable對象
l XmlDocument對象
l XmlDataDocument對象
2）、支持遠程數據傳送的類/方法：
l Serialization類
Serialization類描述了一個將數據轉換爲一種能複製到另一個過程的格式的對象的過程。前面提及的可遠程傳輸的對象具有串行化整個內容的能力，以便它可以通過一個通道來傳送。這個通道可以直接通過TCP/IP，或者通過HTTP。當然，它們也可以在另一端解除串行化，因此客戶機就得到一個原對象的完整副本。
l System.Runtime.Remoting類
System.Runtime.Remoting命名空間提供的對象可用來爲對象創建代理以實現遠程數據傳送。在這種情形下，對象保留在服務器上，並且客戶機只收到一個代理對象的引用。這個代理對象表示原來的基於服務器的對象（這就是我們怎樣遠程使用一個DataReader的方法），示意如下圖：
對於客戶機，這個代理提供了與原始對象相同的方法和屬性。然而，當客戶機與代理對象相互作用時，調用被自動串行化，並通過通道（網絡）傳送給服務器上的對象。然後，任何響應和結果通過通道被傳送回客戶機。
這兩個遠程技術都允許客戶機使用原來在服務器上創建的對象。我們能夠串行化一個DataSet對象或者Xml文檔，同時我們也能串行化其它的如集合這樣的對象--比如一個哈希表(Hashtable)或數組(Array)。
4、N層模型中的數據處理及對象選擇
首先需要考慮的是希望從數據存儲中提取出來的數據做些什麼？這個問題的答案對我們所使用對象的基本選擇的影響將比其他任何事情都要大，甚至在某種程度上定義了我們希望完成任務的性能的種類。
1）、只用於顯示的數據
如果只是想以一種固定格式爲終端用戶顯示數據的話，一般來說根本就沒有必要遠程傳輸數據。我們沒有必要在線上將所有的數據傳送給客戶機--我們只能傳給它們客戶設備能接受的任何格式的最終顯示信息。
在這種情形中，"Reader"對象提供了一種只讀的、僅向前的理想且性能最優的技術。當與能實現服務器端數據綁定的服務器控件一起使用時，我們可以獲得一個顯示數據的高效方法。
2）、需要遠程傳輸的數據
然而，如果我們需要遠程傳輸數據的話則存在一個問題。這些快速而高效的"Reader"對象只在作爲一個引用時才能被遠程傳輸。將一個DataReader作爲引用傳送給一個客戶機時，DataReader仍還在服務器上，不過客戶機的應用程序也可以使用它。在這種情況下，我們實際上並沒有遠程傳輸數據，而是使用了一個遠程傳輸對象。在很多情況下都存在這種情況。
要實現數據的遠程傳送，應該將數據寄存到一個能夠存儲（或保持）數據的對象中。並允許代碼不需進入數據存儲的額外行程就可以根據需要提取數據，並且多次讀取。在ADO.NET中，這個對象就是DataSet對象（或者DataTable對象）。當使用xml時，也有幾個對象供選擇。我們能夠遠程傳輸XmlDocument和XmlDataDocument對象。這兩個對象都有保持內容的能力，並且可以在一個應用程序的層之間進行傳送。
四、N層分佈式數據處理架構模型
要進一步理解怎樣在應用程序中劃分不同的層，需要確定數據如何顯示以及是否需要更新數據和向服務器及時返回更新。
1、全部在服務器上完成顯示
在客戶機上顯示數據，最常見的情形是在一組或者多組服務器上執行所有的數據處理。數據層和中間層限於服務器，客戶機只提供顯示接口。對於一個web瀏覽器來說，通常的格式爲html，對於一個蜂窩式電話或類似設備來說，可能是以wml格式表示，等等。
下圖使用一個存儲過程或SQL語句來提取所需要的數據，然後用asp.net進行處理，或者執行一個web服務。另外，這裏也用xml片段的形式從數據存儲中提取數據，然後對數據進行處理並提供給客戶機。
如果以xml文檔形式存儲數據，或者以這樣一種格式存儲數據：數據作爲xml外置數據層，那麼我們就有一些其他的選擇。
下圖顯示了怎樣提取和處理xml數據以便傳送給客戶機使用。此外，數據的提取其實就是藉助一個"Reader"對象，並且可以使用不同的技術來處理數據並將數據提供給客戶機。
2、擴展中間層
雖然數據的提取和處理經常在一個對象裏發生，比如一個Asp.Net頁面，但是爲了有效利用由於使用基於組件的設計而提供的好處，通常需要提供更爲精細的架構。我們應該有在顯示數據或者將其傳送給客戶機之前應用於數據的商務規則。換句話說，它可能是因爲安全的原因，也可能是爲了實現分佈式處理，或者只是提供可重用性和使應用程序的維護更加容易。
例如，應該有訪問一個數據存儲並提取一系列消費者的多個頁面。通過在一個獨立於asp.net頁面或其他提供數據給客戶機的對象的組件中建立這個過程，我們能夠提供一個提取數據的層。然後，我們在將來需要在某些方面改變數據存儲或者數據結構，或者改變訪問它的規則，我們只要用一個新的版本替換組件即可。
只要組件的接口仍然未變，所有使用這個接口的應用程序將看到來自組件的相同輸出並和以前一樣繼續運行。然而，組件在內部用來提取和處理來自數據存儲的數據的方法可以根據需要進行相應修改。下圖示意了這種架構。
顯然，該過程可以使用多個組件。如果數據的提取相當複雜，或者同一數據運用在多個地方的話，進一步分解數據處理（分解爲更多組件層）就很有意義。例如，可用一個組件將數據當作一系列包含所有必須列的行（以關鍵字順序排列），這個組件就可以成爲其他以不同順序存儲數據的組件，或者僅外置數據的某些列的組件的數據源。
3、移動數據處理到客戶機
一般地，要獲得發送給客戶機的數據，我們將利用客戶端腳本（JavaScript或 VBScript以及 WMLScript）、用Java或者一個特定平臺的語言書寫的客戶端組件，或者用諸如Visual Basic 6.0、C++、Delphi等語言書寫的客戶端可執行程序等等。當然，所有我們需要的功能都是.Net Framework的一部分。（用戶可通過下載和安裝可重新分配的Framework（大約5MB）在客戶機上使用Framework）。
因此，下面的示意圖顯示了一些用於實現獲得發送給客戶機的數據並在客戶機上進行處理的方法。
4、將更新回送給服務器
在許多情況下，如果我們的要求就是以一種儘可能快速和高效的方式獲得發送給客戶機的依據，那麼，上面的示例能很好地完成任務。然而，許多應用程序要求客戶機將數據回送以更新數據存儲等操作時，就需要尋找更合理的模式。
至少有三種方法用於向服務器端回送數據。一是回送Html表單和查詢字符串(實現方式與以前的ASP類似)；另一是客戶端組件(例如IE5及以上版本的XMLHTTP組件)；還有就是客戶端可執行的Windows表單應用程序和服務等。
因此，應該有這樣一種情況：客戶機僅僅要求我們發送一些數據，並且我們讓客戶機完成所有的數據處理。也就是說，客戶機充當某種類型的服務，它將應用程序的數據作爲自己的源數據來使用，然後在它的客戶機已經處理數據後將更改提交回來。
一旦客戶端完成了數據更新，或者已經收集了用戶輸入的新數據，客戶機應用程序就以一種合適的格式打包數據（或者用正確的技術整理數據），並將它提交給服務器進行處理和存儲。
下圖顯示了利用"胖客戶機"來實現這種架構的方法，其中數據在客戶機上進行處理，然後經整理後返回給服務器來更新原始的數據存儲。
仍然地，這不是一個包含所有可能性的圖表。回送數據的方法或許和發送數據的方法沒有什麼聯繫。你應該根據應用程序的實際需求設計合適的模型。
五、結束語
建立可維護、可擴展的站點，開發高效率、高伸縮性的應用程序、實現跨平臺、跨Internet的應用集成、創建N層分佈式應用程序是擺在無數開發者面前的任務。傳統開發方式及技術面臨了困難。
.Net Framework推出的許多新技術爲這些任務的實現提供了相對簡單的解決方案。其中，基於SOAP的Web Service在處理分佈式應用時具有比傳統的DCOM/CORBA明顯的優點，結合基於Web的ASP.NET頁面開發技術和SQLServer數據存儲技術（或Xml文檔），在.Net下開發N層應用程序也不再困難。
要很好地完成以上任務，你需要根據實際情況設計合理的應用程序架構模型。本文正是爲了在這方面爲你提供參考。
參考資料：《ASP.NET Web服務高級編程》、《.Net Framework技術內幕》、《ASP.NET分佈式數據應用程序高級編程》、MSDN在線