.Net開發平臺研究(二)
2024-07-10 12:59:40
供稿：網友
類庫主要的好處是它們將核心win32 api的最常用的功能和外掛sdk的功能封裝到了一個統一的包中。采用清晰而有條理的方式對類庫進行了分組和描述，這樣開發者能更容易地找到他們的應用程序所需的大多數功能。
相反，在過去幾年中，新功能要么被“綁縛”到win32 api上，要由通過獨立的api（例如用于圖形的directx，或者用于xml和soap的不同的sdk）來提供。對它們唯一能做的邏輯分組就是按照字母順序進行排序。結果，使用win32 api和各種sdk經常使人暈頭轉向，而開發者必須判斷幾個類似的api中哪一個最適合他們特定的要求。
支持web services
clr和類庫的結合使得與以前只是在windows上相比，開發web services更為容易。
首先，clr為運行服務器應用程序，包括web services，提供了一個更可靠的基礎。服務器應用程序通常比桌面應用程序要有更高的可用性和安全性的要求，因此它們尤其將從clr捕捉錯誤和阻止惡性代碼的功能中受益。此外，服務器應用程序通常需要長時間不間斷地運行，因此也將從clr的碎片整理功能中受益。碎片整理功能可以限制內存泄露，否則長時間運行的應用程序可能會耗盡所有可用的內存。
混合可控制代碼和不可控制代碼
common language runtime（clr）（通用語言運行環境）的協作功能允許開發者將可控制代碼與com組件中現有的不可控制代碼（以及win32動態連接庫（dll）中的代碼）混合起來。
當一可控制代碼組件調用一com組件（頂層）時，clr就生成一個運行環境可調用包裝（runtime callable wrapper）(rcw）。rcw充當不可控制的com組件的代理（或中介）的角色。rcw處理可控制組件和com組件之間所有的交互，包括（但不限于）以下內容：
·在clr和com環境間翻譯和傳遞數據
·當可控制代碼組件被clr碎片整理進程重新聲明時，釋放包裝的 com組件的內存和其他資源。
·將來自com錯誤返回代碼（hresult值）的錯誤翻譯成clr錯誤（稱作異常）。
當com組件調用用可控制代碼（底層）寫的 .net組件時，clr又生成了一個稱作com 可調用包裝（ccw）的包。和rcw類似，ccw也在不可控制的com代碼和可控制代碼之間充當代理或中介的角色。ccw還實現了com組件所需功能的標準設置，這樣可控制代碼組件看起來就像標準的com組件一樣。
ccw處理不可控制的com對象和可控制的.net組件之間的所有支互，包括（但不限于）以下內容。
·在兩種環境間移動和翻譯數據
·當com組件被釋放時，由clr釋放用于最后的碎片整理的可控制代碼。
·將clr異常翻譯為com返回代碼。
其次，類庫提供了開發者創建web services或使用web services的應用程序所需的全部代碼。特別地，它們提供了在應用程序數據和xml間進行翻譯轉換的代碼，以及通過internet協議收發soap消息的代碼。這樣開發者就可將更多的精力放在他們自己的應用程序的邏輯上，而盡量不去考慮如何實現網絡協議或讀寫xml數據這樣的細節上。
統一平臺:
clr和類庫還聯合解決了微軟當前平臺存在的一個重要問題：所有的編程語言并非是均衡創建的。微軟的每種編程語言都有自己的run-time基礎結構（例如，visual basic [vb] runtime的多個潛在沖突的版本）和軟件庫（例如microsoft c++基礎類）。這就要求微軟維護這些庫以及相關的諸如debugger和wizard等工具。一個組織通常不得不將一個項目分割開來，其中一些讓c++程序員編寫，另外一些則讓vb程序員來寫。任一種程序員的短缺都會影響進度。
.net framework采用以下兩種方法來解決語言的劃分問題。
標準化數據類型。首先，.net framework為最常用的數據類型（例如整數、實數、文本字符）提供了標準的內部描述和運算，并提供了將這些類型向所有的.net語言和clr擴展的機制。設立這種標準化數據類型和可擴展模型（全稱為.net framework common type system (cts)），消除了每種語言用它自己唯一且不兼容的方法實現數據類型的必要。
標準化應用程序格式。其次，.net framework實現了一個標準的應用程序格式——擁有自己的msil、元數據和清單的匯編。所有.net語言的編譯器都生成這種格式。通過從元數據中提取有關msil的信息，編譯器、調試器和協議器等工具可以分析處理任何一種源程序設計語言的數據。
標準化的數據類型和應用程序格式使開發者可以創建用任一種理解其中的數據類型和格式的程序設計語言工作的類庫，這樣的類庫包含所有微軟的.net編程語言以及眾多的第三方廠商語言。特別地，.net framework類庫僅使用cts數據類型，并分配以標準的應用程序格式。結果，這些類庫能被使用任何一種.net編程語言的應用程序所使用。
（請參看“開發可控制代碼”示意圖。）
clr和類庫相結合為微軟提供了一個單一的運行平臺，它支持運行所有的編程語言，并且可以用一組公共的開發工具來實現它。微軟已經發布了一個該平臺和它所使用的語言的規范。（請參看“ecma標準和windows lock-in。）此外，類庫向所有的.net編程語言提供了大致相同的基本功能組，這樣就使程序員可以用任一種他們最拿手的語言來工作。
.net類庫域名空間
.net開發平臺提供的api 被組織安排到了一組帶有邏輯名的分級域名空間中。（本示意圖顯示了幾個比較重要的類。）這和win32 api形成了尖銳對比，win32 api只是一個簡單的功能名的長列表，頂多可以按字母排序。有了分級制度以后開發者就可以更加快捷地定位所需的功能，而且添加新的api也不會與已有的發生沖突。
類建立在基礎類（底層）之上，基礎類具有下述能力：文本處理（system.text）網絡訪問（system .net），以及存儲列表和其他數據集（system .collections）等。
基礎類之上是更復雜的類，例如數據訪問（system .data），它包括add.net和xml處理（system .xml）。
頂層是用戶接口庫。windows 表單和drawing庫（分別是system.win表單和system .drawing）提供了封裝后的windows用戶接口，包括gdi+和directx .system。web包含用于建立包括web services類和web 表單用戶接口類的asp.net應用程序的類庫。
開發可控制代碼
開發者通過將他們自己的應用程序源代碼和來自.net類庫的代碼相結合，創建了可控制代碼。這些類庫可能包括.net開發平臺包含的類庫（例如ado.net和windows 表單），以及來自第三方的類庫。
接下來.net編譯器將此代碼從人可讀的格式翻譯成microsoft intermediate language （msil）。不管采用何種語言，所有的.net開發平臺編譯器均生成msil結果。
除了msil，.net編譯器還產生元數據，它描述了彌補代碼的組件。common language runtime (clr）（通用語言運行環境）使用這種元數據來增強安全性，并確保獲得它所需的任何組件的正確版本（減少組件沖突，或者“dll hell”）。
visual studio .net和其他工具自動將msil代碼封裝到clr中使用的匯編中。幾個msil文件可以被組合成一個單一的匯編。（有關一個匯編如何由clr來執行的圖解概貌，請參看“執行可控制代碼”示意圖。）
6.net開發平臺與j2ee的比較
作為彼此競爭的應用程序平臺，微軟 的.net開發平臺和sun 的java 2 enterprise edition（j2ee）（java 2企業版）在意圖和體系上極其相似，但在底層實現上卻完全不同。
類似的目標 :
.net開發平臺和j2ee在精神實質上具有類似的目標：
ø 采用更易于重用別人創建的代碼組件的程序設計模型，通過向開發者提供已有的組件，消除了重寫底層例程的必要，從而提高開發者的開發效率。
ø 通過消除或減少對c這樣的開發語言的易出錯結構的使用，以及使用強迫對所有代碼組件間的交互點作清晰定義的編程模型（這隔離了錯誤的影響，并且使錯誤跟蹤更為容易），增強了軟件的可靠性。
ø 通過對應用程序可以或不可以做什么（例如它們是否可以讀/寫磁盤）加以控制，并且在運行時采用數字簽名以確認代碼是由信任的實體編寫的且尚未被改變，來提高安全性。
ø 通過在代碼自身內嵌入組件描述（包括版本信息）來簡化安裝和卸載。這免除了讓開發者在安裝時“注冊”他們的代碼的思想——這是以前安裝復雜和不穩定的一個主要原因—— 從而使需要時，沒有或很少有用戶或者管理員的干預，應用程序軟件即可自動安裝成為可能。在.net開發平臺的情形中，它還允許同一組件的不同版本共存于一個系統，彼此間互不干涉，也不與其他應用程序相干涉。
類似的體系結構:
由于目標類似，.net和j2ee兩個開發平臺也有著類似的體系結構。相應的體系結構特征如下：
ø 虛擬機：設計它用來檢查、加載和執行在一個牢牢受控的“沙箱”（sandbox）中的程序。通過在程序代碼可以做和不可以做什么之間設置嚴格的邊界，這個沙箱減少了由惡性代碼（例如病毒）和信任代碼偶然的行為造成的危險。為了啟用這個沙箱體系結構，所有的程序都被從原始代碼編譯成了與處理器無關的中介語言——microsoft intermediate language（msil）或java位碼。然后在稱作just-in-time（jit）編譯器的參與下，這些中介代碼單元被翻譯成了針對特定cpu類型和操作系統的本機代碼。這個虛擬機還向程序提供了諸如內存管理等基礎服務。.net的虛擬機稱作common language runtime（clr），j2ee使用java virtual machine（jvm）(java虛擬機）。
ø 類庫：向應用程序開發者提供預先寫好的功能，包括：編碼服務（例如字符串操作和事務處理），網絡服務（協議處理），系統管理服務（安全許可和組件合并），服務器服務（為web頁服務，連結e-mail），以及連結外部源（例如數據庫系統和數據流）的服務。
ø 定制的編程語言：建立在c和c++基礎之上，包括諸如強類型化和能提高開發者開發效率并降低bug出現的可能性等改進。不過，只要有編譯器能將初始的源代碼翻譯成為虛擬機能夠理解的中介代碼，就沒有必要用這些語言（c# for .net或者java for j2ee）來寫程序。clr現在支持c#、visual basic、 jscript、 coblol、 fortran、 haskell以及python（由的三方開發的帶有許多其他語言的工具）；jvm支持java、cobol、ada以及prolog等。
ø 用于運行在web服務器上的動態web頁的開發環境：這讓開發者使用相同的平臺既可創建桌面應用程序，又可創建基于web的應用程序，.net使用asp..net，而j2ee使用java server pages（jsp）。
7. .net開發平臺工具:
和先前從win16到win32 api的平臺轉換不同，從win32到.net開發平臺的轉換既有對已有語言和工具的修改，還引入了全新的語言。結果，決定使用.net開發平臺的組織，不僅必須改變它們的平臺戰略，而且還必須考慮它們的語言和工具戰略。
.net開發平臺語言
將有三種新版的微軟編程語言支持clr和類庫：visual basic.net, visual c++，以及jscript.net。它們還將結合兩種新語言：visual c#和visual j#。visual j#使visual j++開發者可以使用類似的語言創建可控制代碼。
微軟經常指出，.net開發平臺和諸如java等其他編程環境之間的最大的差別在于，.net開發平臺支持多種編程語言。（有關.net開發平臺與java之間差別的更多信息，語參看邊框內容 （“.net開發平臺與j2ee的比較”。）由于.net開發平臺支持不同的語言，具有不同技巧的程序員就可以使用他們最擅長的語言來創建組件，而這些組件可以平滑地協作。但這也帶來一個問題——開發和項目經理如何選擇他們的應用程序所用的語言。
microsof的每一種支持cir和類庫的語言都有著不同的實現和歷史，做選擇時需要加以考慮。（為獲得選擇.net開發語言的快速指南，請參看邊框內容“選擇.net語言的經驗規則”。）
visual basic .net
這種新的語言擁有與現有的visual basic（vb）類似的語法，設計它的目的是為了讓使用vb的開發者能過渡到.net。不過，和以前的vb版本不同的是，visual basic.net使用clr和類庫取代了類似的vb組件和插件。vb.net還有新的、高級的功能，例如對多線程和結構化異常處理的支持。盡管如“onerror goto”型的錯誤處理的語言習慣的去除是一項受歡迎的改變——這會使應用程序更加健壯，但卻意味著現在的vb程序員不能加載并運行他們以前的應用程序。
事實上，vb.net與以前的vb版本相比有很大的改變，不能向后兼容。微軟正在開發一個工具，用于將vb源代碼遷移成vb.net代碼，但是這個過程不能全部自動完成。開發者必須手工檢查遷移后的代碼，重寫某些部分，并仔細測試結果。
不過，開發者不必一次遷移所有代碼：幸賴clr的協作功能，vb.net可以調用vb代碼，反之亦然。這就允許開發者逐漸遞增地遷移應用程序——例如，一個vb.net應用程序可以合并一些已有的vb模塊。
由于遷移不能馬上完成，微軟答應它將繼續支持現在的vb語言（6.0版），至少到vb .net的第三版發布，根據vb發布的慣常速度，那大概要等到五、六年之后。
兩個vb的變種根本不能遷移到.net開發平臺上：一種是visual basis scripting edition（vbscript）（visual basic腳本描述版本），用于管理腳本、active server pages (asp）（活動服務器頁）與動態web內容的腳本描述語言；另一種是visual basic for applications (vba），用于定制諸如office等應用程序的腳本描述語言。vbscript已經包容在vb.net中，而vba則將繼續作為office中的宏程序設計語言發揮作用。
微軟說在向.net開發平臺遷移時，過去使用vb的開發者應使用vb.net而非c#。這只是一個初步分析的結論，具體情況還需考慮開發者使用的vb功能的廣泛程度：
·對于多數一般的vb程序員，大多數的語言改變相當直接。如果vb開發者的主要經驗是使用已有的vb組件，那么他們應當使用vb.net進行新應用程序的開發，而不能轉到使用c#上去。像c#這樣的更為嚴格的面向對象語言的附加的復雜性與任何獲得的小的收益都不成比例。
·高級的vb程序員——例如，那些廣泛使用諸如“win32 declare”這類對底層os進行直接調用的功能的開發者——則另當別論。使用vb.net，他們現在能發揮自己的本領創建應用程序底層的組件，例如那些供其他vb程序員使用的組件。不過，因為他們要設計供團隊內其他成員使用的組件（即使團隊的其他人繼續使用vb.net），這些組件開發者也應考慮切換到c#對于組件開發的好處。
