基於.Net Framework的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層模型中的表示層（圖中左列）用於資料顯示。中間列是中間層，處理商務邏輯；右列是資料層，處理資料儲存。
隨著一個基於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層應用程式也不再困難。