基于.Net Framework的N層分布式應用開發
.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層模型中的表示
層（圖中左列）用于資料顯示。中間列是中間層，處理商務邏輯；右列是資料層，處理資料存儲。
随着一個基于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層應用程式也不再困難。
posted on
2011-08-26 09:45
HackerVirus
閱讀(183)
評論(0)
編輯
收藏
舉報
