網友原創:從N層到.NET詳細剖析原理

來源:互聯網
上載者:User
原創

  摘要:討論 Microsoft .net 的應用程式設計和所需的更改:檢驗從使用 Microsoft Windows DNA 構建 N 層應用程式中學到的結構知識,以及如何將這些知識應用到使用 Microsoft .NET 架構構建的應用程式,並且為使用 XML Web Services 的應用程式提供體繫結構方面的建議。

  簡介

  如今,N 層應用程式已經成為構建企業軟體的標準。對於大多數人來說,N 層應用程式就是被分成多個獨立的邏輯部分的應用程式。最常見的選擇是分為三個部分:表示、商務邏輯和資料,當然還可能存在其他的劃分方法。N 層應用程式最初是為瞭解決與傳統的用戶端/伺服器應用程式相關的問題而出現的,但是,隨著 Web 時代的到來,這一體繫結構開始成為新開發項目的主流。

  Microsoft Windows? DNA 技術已成為 N 層應用程式的非常成功的基礎。Microsoft .NET 架構也為構建 N 層應用程式提供了堅實的平台。然而,。NET 所帶來的變化使結構設計人員應當重新考慮他們在 Windows DNA 領域中所學的有關設計 N 層應用程式的某些知識。更重要的是,對內建於 .NET 架構的 XML Web services 的基本支援允許開發人員構建突破傳統 N 層方法的新應用程式。要瞭解如何更好地構建 .NET 應用程式的體繫結構,您需要瞭解這一新領域中發生了哪些變化,以及如何充分利用這些變化。

  本文將對這些問題進行討論。首先回顧一下在使用 Windows DNA 構建 N 層應用程式中學到的關鍵體繫結構知識。然後,再按同一順序將這些知識應用到使用 .NET 架構構建應用程式的過程中,從而對它們進行檢驗。最後一部分對使用 XML Web services 的應用程式的體繫結構提供了一些建議。

  Windows DNA 環境

  將應用程式恐解成多個邏輯部分是很有鈾的。將一個大軟體分成幾個小的部分會更利於軟體的構建、重複利用和修改,對適應不同的技術或不同典業務組織也很有協助。同時,還有一些綜合因素需要考慮。雖然模組化和重複使用性很有效,但它們可能會導致贏用程式不能象使用其他方法那樣安全、易管理和快速。本節將回顧一些從使用 Windows DNA牸際豕菇?N 層應用程式的普遍經驗中所獲得的基1咎逑到峁怪丁?

  編寫商務邏輯

  Windows DNA 應用程式通常使用以下三種實現方式中的一種或多種方式來實現其商務邏輯:

  ●ASP 頁

  ●COM 組峻,可能使用 COM+ 提供的其他服務

  ●在 DBMS 中啟動並執行預存程序

  一般來講,在 ASP 頁中編寫過多的商務邏輯並不是一個好辦法。因為必須使用簡單的語言,例如 Microsoft Visual Basic? Script (VBScript),而且每次執行時都要解釋代碼,這會對效能造成影響。而且 ASP 頁中的代碼不好維護,主要是因為商務邏輯通常與建立使用者介面的表示代碼混合在一起。

  鑒於這種情況,建議在編寫中介層商務邏輯時,將商務邏輯當作 COM 物件來實現。這種方法比編寫純粹的 ASP 應用程式要稍微複雜一點,但是可以使用全功能語言來產生編譯好的可執行檔,因此其結果要快得多。將商務邏輯封裝在 COM 物件中還可以將此代碼與包含在 ASP 頁中的表示代碼完全分隔開來,從而使應用程式更易於維護。

  從 COM 到 COM+,其體繫結構相差無幾。但是,正如許多 Windows DNA 體繫結構設計人員所瞭解的,除非真正需要,否則不應使用 COM+ 提供的核心服務,如事務、即時 (JIT) 啟用、角色型安全性和線程服務等。使用其他開發平台提供的 COM+ 或類似服務自然會導致應用程式速度更慢、更複雜。只有在以下情況下使用 COM+ 才有意義:

  ●需要跨越不同資源管理員(如 Microsoft SQL Server? 和 Oracle)的分散式交易。

  ●應用程式可以有效地利用角色型安全性。

  ●可以增強 Microsoft Visual Basic? 6.0 的線程操作。

  ●JIT 啟用能夠提高效能;瀏覽器用戶端很少出現這種情況,因為 ASP 頁是通過 JIT 有效啟用的。

  ●COM+ 的配置優勢大大簡化了應用程式的部署。

  編寫商務邏輯的第三種方式是,建立一些作為預存程序在資料庫管理系統 (DBMS) 中啟動並執行代碼。儘管使用預存程序的主要原因是將資料庫結構描述的詳細資料與商務邏輯分隔開以簡化代碼的管理和提高安全性,但代碼與資料如此接近也有助於最佳化效能。那些必須獨立於 DBMS 的應用程式(例如由獨立的軟體供應商建立的應用程式)通常要避免使用這種方法,因為它會將應用程式鎖定到某個特定的資料庫系統中。預存程序的編寫和調試可能會比 COM 物件的編寫和調試難,而且此方法會減少重複使用代碼的機會,這是因為 COM 物件通常比預存程序更易於重複使用。但是大多數自訂應用程式仍然串連到最初建立它們的 DBMS 上,因此使用預存程序的效能優勢還是很大的。鑒於這種情況,那些必須儘可能運行良好的 Windows DNA 應用程式通常對部分或全部的商務邏輯都使用預存程序。

  構建用戶端

  Windows DNA 既支援用 Visual Basic 等語言編寫的本地 Windows 用戶端,也支援瀏覽器用戶端。瀏覽器用戶端的局限性較大,尤其同時將 Microsoft Internet Explorer 和 Netscape 作為瀏覽器時。因此,應用程式通常同時擁有瀏覽器用戶端和本地 Windows 用戶端。瀏覽器用戶端提供的介面很有限,但用它可以方便地訪問 Internet,而 Windows 用戶端能提供全功能的介面。使用可下載的 Microsoft ActiveX? 控制項可以建立更複雜的瀏覽器介面,但必須確保瀏覽器是 Internet Explorer,並且使用者願意信任應用程式的建立者。

  管理瀏覽器應用程式中的狀態

  ASP 應用程式可以使用幾個不同的機制來維護伺服器上用戶端請求之間的資訊。但是 Windows DNA 中有一條嚴格的規則,如果應用程式在兩台或多台機器之間平衡負載,則絕對不能使用 ASP Session Object Storage Service每個用戶端的狀態。ASP 的 Session 對象被鎖定在一台機器上,因此不能用於Server Load Balancer的應用程式。

  ASP Session 對象和 ASP Application 對象還有另一個限制。使用它們中的任何一個來儲存 ADO 記錄集都會大大降低延展性,因為它限制了應用程式開發多線程的能力。因此,在這兩個對象的任何一個中儲存記錄集都不是好辦法。

  分布式通訊

  在 Windows DNA 中,選擇運行在不同機器上的組件的通訊方式非常簡單:DCOM 可以說是唯一的選擇。單純從體繫結構上來看,DCOM 是 COM 的簡單擴充。但實際上,DCOM 還有許多其他含義,其中包括:

  ●由於實際上是其自有協議,因而使用 DCOM 與遠程 COM+ 對象進行通訊非常直接。

  ●只要配置正確,DCOM 將是非常安全的協議。但是要實現這種配置並不容易,因此該協議不太容易使用。儘管如此,DCOM 自身仍能提供很好的分布式身分識別驗證、資料完整性和資料保密性,特別是在 Windows 2000 域內。

  ●由於 DCOM 需要開啟任意連接埠,因此不適合與防火牆配合使用。所以,對於必須通過 Internet 進行通訊的應用程式,一般不能使用 DCOM.

  訪問儲存資料

  可以將使用 ADO 構建的資料訪問體繫結構分為兩類:輕型和重型。輕型 ADO 用戶端儘可能簡短地保持資料庫連接,並使用預存程序寫入資料庫。輕型用戶端使用以下三種方法之一檢索資料:

  ●通過使用唯讀、僅向前遊標填充記錄集;

  ●通過預存程序輸出參數;

  ●使用資料流(在 ADO 的較新版本中)。

  重型用戶端則會較長時間地保持資料庫連接。這類應用程式依賴於開放式串連,以及那些串連所允許的有狀態的伺服器端遊標,以:

  ●使記錄集能夠直接存取其他使用者或應用程式所做的更改;

  ●啟用保守式鎖定;

  ●儘可能減少複製到 ADO 用戶端的資料量,以減少網路通訊量。與輕型用戶端不同,使用伺服器端遊標的用戶端可以將查詢結果保留在資料庫內,直到真正需要這些資料時再取出。此外,這種方法向記錄集複製的中繼資料較少,而把更多的資料保留在資料庫中。

  輕型應用程式最具伸縮性,因為它們最有效地使用了資料庫連接這一稀有資源。相比之下,重型應用程式必須保持長期有效資料庫連接,因為這是有狀態的伺服器端遊標所要求的。這就大大地限制了應用程式的延展性,尤其不適用於 網際網路服務器應用程式。儘管使用 ADO 開發重型應用程式可能更簡單,但通常這並不是最佳選擇。

  ADO 也不是特別適用於處理 XML 文檔等分層資料。ADO 完成此項工作的功能用法複雜,且不易理解。同樣,ADO 僅為訪問 SQL Server 2000 的 XML 功能提供有限支援,因此,Windows DNA 應用程式通常都避免使用 ADO 處理分層資料。

  將資料傳遞到用戶端

  對於所有 N 層應用程式而言,將資料從中介層有效地移動到用戶端都是一個關鍵的環節。當使用 DCOM 與 Windows 用戶端通訊時,Windows DNA 應用程式可以使用 ADO 中斷連線的記錄集。當確保瀏覽器為 Internet Explorer 時,此選項也可用於瀏覽器用戶端。而將資料發送到任意瀏覽器則比較困難。一種方法是顯式地將資料轉換為 XML,然後將資料和所有必要的指令碼代碼發送到瀏覽器。

  .net 環境

  .NET 支援傳統的 N 層應用程式、Web Services 應用程式以及將二者的元素結合在一起的應用程式。本節首先介紹 .NET 如何影響 N 層應用程式,然後介紹構建 Web services 應用程式過程中的幾個主要的體繫結構問題。

  將 N 層應用程式與 .NET 綁定在一起

  上一節中介紹的某些問題同樣適用於 Windows DNA 應用程式和使用 .NET 架構構建的應用程式。例如,只有當滿足前面所列的一個或多個條件時,才能使用 COM+(在 .NET 架構中稱為企業服務)。同樣,將商務邏輯構建為預存程序在很多 N 層應用程式中都可以獲得更好的效能。

  同時,。NET 架構中到處都是新技術和現有技術的新版本。這些增強功能為 N 層應用程式的最佳化體繫結構帶來了多種變化。本節將按照前面介紹的分類,介紹 .NET 架構是如何改變體繫結構設計人員在建立 N 層應用程式時所做的決定的。

  編寫商務邏輯

  與在 Windows DNA 中建立 N 層商務邏輯的三種可選方法(ASP 頁、COM 組件和預存程序)不同,。NET 架構只提供了兩種方法:程式集和預存程序。對於瀏覽器應用程式,可以使用 Microsoft ASP.NET .aspx 頁來建立程式集。與 ASP 不同,在這種情況下完全使用 ASP.NET 編寫商務邏輯通常是一個比較好的方法。

  其中一個原因就是 ASP.NET 的內含代碼選項。在傳統的 ASP 頁中,以一種可維護的方式混合業務代碼和表示代碼並不是一件容易的事,而 .aspx 頁使用內含代碼能夠完全將這兩種代碼分開。Windows DNA 應用程式可能需要同時使用 ASP 頁和 COM 物件才能實現可維護性,而使用 .NET 架構構建的應用程式則只需使用 ASP.NET.此外,。aspx 頁中包含的商務邏輯可以用任何基於 .NET 的語言編寫,而不僅限於傳統 ASP 頁所支援的簡單的指令碼語言。而且,ASP.NET 是編譯頁面而不是解釋頁面,因此 ASP.NET 應用程式速度可以非常快。雖然使用 Windows DNA 構建的應用程式可以使用 ASP 頁和 COM 物件來達到足夠高的效能,但 .NET 只需使用 ASP.NET 便可構建具有同樣優良效能的應用程式。最後,商務邏輯使用 ASP.NET 緩衝來減少對包含常用資料的資料庫的訪問,這樣可以大大提高效能。

  但是,需要指出的是,對於包含在 .aspx 頁中的代碼,即使是使用內含代碼,其重複使用也比標準的程式集困難。例如,從 Windows 表單用戶端訪問 .aspx 頁中的代碼會遇到很多問題。

  構建用戶端

  使用 .NET 架構可減少對 Windows 用戶端的需求,通常只需要一個瀏覽器用戶端即可。其中一個原因在於,ASP.NET Web 控制項允許構建和/或購買可重複使用的瀏覽器圖形化使用者介面 (GUI) 元素,從而能夠更方便地構建更有用的瀏覽器用戶端。而且可以將基於 .NET 架構的組件下載到 Internet Explorer 用戶端,然後使用部分信任來運行這些組件(而不使用 ActiveX 控制項所要求的全是全非信任模式),這有助於構建更好的使用者介面。

  管理瀏覽器應用程式中的狀態

  由於 ASP Session 對象被綁定到一台機器上,因此它並未發揮出應有的作用,而使用 .NET 架構就避免了這種限制。與 ASP 不同,ASP.NET Session 對象可以被兩台或多台機器共用,從而可以使用 Session 對象來維護Server Load Balancer的 Web 服務器領域中的狀態,使其更加有用。而且,由於 Session 對象的內容可以選擇儲存在 SQL Server 資料庫中,這種機制可用於出現故障時必須一直保持每個用戶端的狀態的應用程式中。

  影響 ASP.NET 應用程式體繫結構的另一個重要更改在於,資料集可以儲存在 Session 和 Application 對象中而無需包含線程,這一點與 ASP 不同。也就是說,在 Windows DNA 中嚴格規定的不能將記錄集儲存在這些對象中的規則不適用於 .NET 架構中的資料集。這就使得查詢結果的儲存更加簡單也更加自然。

  分布式通訊

  與 Windows DNA 相比,.NET 架構為應用程式的分布式組件之間的通訊提供了更多選擇,包括:

  ●。NET Remoting,提供 TCP 通道和 HTTP 通道;

  ●ASP.NET 支援在 .asmx 頁中實現的、可通過 SOAP 調用的 XML Web services;

  ●與遠程 COM 物件通訊所需的 DCOM.

  選項越多,意味著體繫結構的選擇也越多,這也意味著做選擇時有更多需要考慮的因素。使用 .NET 架構建立分布式應用程式時要瞭解的體繫結構問題包括:

  ●直接與遠程 COM+ 對象進行通訊要求使用 DCOM,而不能使用 .NET Remoting.由於 DCOM 的建立和使用都相當複雜,因此應盡量避免這種通訊。在某些情況下,有必要通過Managed 程式碼處理現有的 COM+ 對象,儘管這樣做所要求的 COM Interop性會降低效能。

  ●。NET Remoting TCP 通道沒有提供內建的安全性。與 DCOM 不同,它不提供嚴格的身分識別驗證、資料完整性或資料保密服務。但它並非一無是處,TCP 通道比 DCOM 更容易配置。

  ●DCOM 不能很好地與防火牆配合使用,。NET Remoting HTTP 通道與之不同,它是專門為在 Internet 上進行有效通訊而設計的。而且,由於可以使用 SSL,此選項能夠為資料提供安全的路徑。通常,對於 Intranet 通訊而言,TCP 通道是較好的選擇;而對於 Internet 通訊,則更適合使用 HTTP 通道或 ASP.NET SOAP 支援。

  ●。NET Remoting HTTP 通道和用於 XML Web services 的 ASP.NET 支援都能實現 SOAP.但這兩種實現卻截然不同,各有其特定的目的。。NET Remoting 注重保持通用語言執行平台的確切語義,因此當遠程系統也運行 .NET 架構時,它是最佳選擇。ASP.NET 則注重提供絕對標準的 XML Web services,因此當遠程系統是基於 .NET 的平台或任何其他平台時,它是最佳選擇。而且 ASP.NET 比 .NET Remoting HTTP 通道的速度快。但 HTTP 通道也有優點,它允許通過引用和真正的非同步回調來傳遞參數,這是 ASP.NET 中的 SOAP 支援所不具備的功能。

  訪問儲存資料

  ADO 能夠方便地構建重型用戶端,但用戶端的伸縮性較差,ADO.NET 與 ADO 不同,它更適用於構建輕型用戶端。ADO.NET 用戶端使用僅向前的唯讀遊標讀取資料。它不支援有狀態的伺服器端遊標,因此其編程模式鼓勵短時間的串連。直接讀取和處理資料的用戶端可以使用 ADO.NET 的 DataReader 對象,它不為返回的資料提供緩衝。或者,可以將資料讀入 DataSet 對象中,將其作為從 SQL 查詢和其他源中返回的資料的緩衝。但是,與 ADO 記錄集不同,資料集不能顯式地維護與資料庫的開放串連。

  如前面所述,ADO 產生的重型方法還存在一些其他問題。這些問題可以在 ADO.NET 中解決,如下所示:

  ●對於將資料存放區在資料集並要求訪問由其他使用者或應用程式所做的更改的 ADO.NET 用戶端,需要包含顯式代碼才能進行這些更改。該代碼通常還需要為每個所進行的檢查開啟一個資料庫連接。

  ●儘管 ADO.NET 並不直接支援保守式鎖定,但通過使用 ADO.NET 事務或在預存程序中實現所需的功能,用戶端仍然可以獲得同樣的效果。

  ●與 ADO 不同,ADO.NET 不允許將部分查詢結果保留在資料庫中(可以使用伺服器端遊標從中進行訪問)。雖然 ADO.NET 確實比 ADO 檢索的中繼資料要少,但應用程式仍應設計為能夠將所有的查詢結果從資料庫傳遞到 ADO.NET 用戶端。

  ADO.NET 中影響體繫結構選擇的另一項更改是其對處理分層資料(特別是 XML 文檔)的支援增強了。將 ADO.NET 資料集轉換成 XML 非常簡單,就象訪問 SQL Server 2000 的 XML 功能一樣。因此,在 Windows DNA 中可能被強制裝入關聯式模式中的分層資料現在可以以其原始形式提供訪問。

  將資料傳遞到用戶端

  將資料有效地傳遞到用戶端對於在 .net 架構上構建的 N 層應用程式和使用 Windows DNA 構建的應用程式同樣重要。一項重要的更改在於,ADO.NET 資料集可自動序列化成 XML,從而使得各層之間的資料傳遞更加簡單。雖然在 Windows DNA 中也可以使用這種方法,但 .NET 使通過 XML 的資訊交換變得更加簡單、直接。

  XML Web Services 體繫結構

  在構建分布式應用程式的過程中,可以通過多種方法來使用 XML Web services 的 SOAP、Web Services 說明語言 (WSDL) 以及其他技術。例如:

  ●使用 SOAP 而不是僅僅使用 HTTP 串連到 N 層應用程式的 網頁用戶端。串連建立後,該用戶端可以是能夠進行 SOAP 調用的任意裝置。之後,用戶端可以為其使用者提供更多的功能,因為它能夠直接調用遠程伺服器中的方法。

  ●將可能是在基於 .NET 架構的平台上構建的 N 層應用程式與在其他平台(例如 Java 應用程式伺服器)上構建的另一個應用程式串連起來。

  ●串連兩個大型應用程式,或者串連一個企業資源規劃 (ERP) 系統與另一個 ERP 系統或任何其他應用程式。正如這些樣本所示,XML Web services 不僅僅適用於 N 層應用程式,其應用範圍十分廣闊。

  不管如何使用,XML Web services 都會帶來許多新的體繫結構問題。XML Web services 與 N 層應用程式通常使用的更為傳統的中介軟體技術之間的最主要的差別或許在於,XML Web services 提供的是“鬆散耦合”。遺憾的是,這個詞對於不同的使用者有著不同的含義。在本文中,它是指具有以下特點的通訊應用程式:

  ●應用程式在很大程度上相互獨立,並且通常由不同的組織控制。

  ●並不完全可靠。不能保證每個通訊應用程式在所有時間都可用。

  ●其互動操作可以是同步的,也可以是非同步。Web services 用戶端可能阻塞對某個請求的響應的等待,也可以在發出請求後去做其他事,稍後再來檢查響應。

  ●這些基本特點為使用 XML Web services 的應用程式提供了很多體繫結構方面的原則。雖然有些問題可能會在以後的工作中得到解決,如 Microsoft 的 Global XML Web Services Architecture (GXA) specifications(英文),但是目前,建立有效 XML Web services 應用程式的使用者必須要瞭解這些問題。其中包括:

  ●安全性可能會比較複雜。預先規劃端對端身分識別驗證和有效授權十分重要。端對端的資料完整性和資料保密性對某些應用程式也很重要。可能有必要在不同的安全機制之間進行映射,當然最好盡量避免這種情況。互通性可能會成為問題。由於規範還相對不成熟,不同供應商的 SOAP 實現還不能始終很好地協作。

  ●修改現有應用程式以便可以通過 XML Web services 進行訪問時,可能會出現問題。當把從未打算要在一起使用的程式串連在一起時,總會出現速度、延展性和安全性等問題。現有應用程式通常不是作為伺服器而構建的,因此處理一些很小的請求就會輕易搞垮它們。減少請求數量,而增加每個請求中包含的資料可能會提高應用程式的效能。此外,現有應用程式通常不能處理預料之外的負載,例如向 Internet 公開軟體時可能產生的負載。如果可能,使用某種排隊機制以在請求被響應之前將請求儲存起來,這可能會有所協助。

  ●調節故障非常重要。尤其是只需要一次語義的請求,通常需要格外小心。例如,請求可能會逾時,從而觸發重試,但原來的請求可能只是因為某種原因被延遲而已。如果針對單個調用執行兩次遠程 Web service 會出現問題,則必須建立某種機制來解決這個問題。

  ●不可能提供依賴於分布式鎖定(跨越組織邊界保持)的端對端事務。大多數組織不允許“外來”應用程式鎖定資料,因此不可能實現兩階段交易認可樣式的事務。而只能考慮為任何必要的復原使用補償事務。

  ●由於收到的資料可能跨越應用程式和組織邊界,Web services 通訊的每一端可能都需要仔細檢查該資料。雖然應用程式的建立者可能十分信任由他們自己的應用程式的其他部分所產生的資料的準確性,但他們不能對其他應用程式抱以同樣的信任。收到的資訊甚至可能包含惡意代碼,因此必須仔細檢查。

  ●SOAP 及其攜帶的 XML 定義的資料非常多。在一個調用中傳遞太多資料可能會搞垮低頻寬的網路。反過來,在一個調用中傳遞的資料太少又會搞垮處理這些請求的應用程式。儘管這很困難,但找到正確的平衡點還是很重要的。

  小結

  體繫結構是關鍵。為應用程式(尤其是分佈於多個系統的應用程式)選擇正確的結構是至關重要的。如果選擇了錯誤的體繫結構,不管開發人員多麼優秀,通常都無法在實現過程中修複。錯誤的決定會導致效能降低、安全性降低以及應用程式需要更新時可用的選項較少。

  Windows DNA 為 N 層應用程式奠定了一個堅實的基礎,Windows 開發人員可以根據他們從 DNA 領域所學到的知識來構建應用程式,把其中的大部分應用到新的 .NET 環境中。不過,瞭解本文所建議的更改將有助於建立更快、更安全、功能更強的應用程式。對於 N 層應用程式以及採用 Web services 新技術的應用程式來說,。NET 可提供的功能很多。



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。