微軟 .NET
2024-07-10 13:04:49
供稿：網友
關鍵詞：.net、xml（可擴展標記性語言）、soap（簡單對象訪問協議）、windowsdna、集合（assembly）、通用語言運行時（clr）、il（中間語言）、元數據（metadata）、名空間（namespace）、c#
一、 序言
什么是.net？不同的人有不同的解釋方式。有人認為.net是一種全新的下一代可視化開發環境；有人認為.net是一種新的針對internet時代的開發語言---c#；有人認為它是基于xml（可擴展標記性語言）和soap（簡單對象訪問協議）的新型信息交換平臺，是面向未來的企業級的開發平臺。也有人認為.net只不過是windowsdna技術的演變。類似這樣的定義非常多，這些說法都對，但是都只是涉及到了.net的一部分。首先應該肯定的是.net是一場技術上的革命。在當今社會，技術進步是每天都發生的，但革命不是經常有的。在微軟的歷史上，從dos到windows32是一場技術革命，從windows32到windowsnt也是一場技術革命。隨著internet的飛速發展，軟件開發的難度正逐步加大，現有的開發平臺和開發環境與技術不論是從開發技術上還是從開發模式上越來越無法滿足internet時代的需要的基于web的應用程序和web服務，就是在這種環境下，微軟推出.net，可以毫不夸張的認為，.net是一場革命。在后面對.net的深入討論中，我們更能體會到這一點。
二、.net框架的組成
如圖1所示，.net框架由許多方面構成，在整個結構體的最重要的是系統服務（system service）和通用語言運行時(common language runtime)。其中通用語言運行時提供很多服務來簡化代碼的開發和應用程序的部署（deployment），同時在可靠性和安全性方面也提供大量的服務。.net框架也包括一系列的基礎類庫，這些基礎類庫可以為任何一種基于.net的編程語言使用，通過后面的討論就會發現在此基礎上可以實現代碼級的重用。在框架的最上層，.net提供了一系列組件（注意：在.net中也許用集合（assembly）這個詞代替組件更合適），極大地豐富了開發，不論是開發基于windows的應用程序，還是開發基于web的應用程序。
首先討論集合（assembly），從表面上看，似乎在.net框架中根本未提到集合的概念，但實際上集合是無處不在的，集合可以認為是受管理的組件。在現在的開發模式下，代碼經過編譯后生成exe文件或dll文件，這些dll或exe都是針對某一種特定的cpu的，都是直接以機器碼的方式存在。這種方式的弊端已經讓幾乎所有人都嘗過苦頭了---dll陷阱。在實際生活中，經常遇到這樣的情況，在升級了某一種dll的版本后，發現一些原來老版本的功能出現了問題，甚至出現內存沖突、死機等問題。而在集合中，由于代碼的生成是以中間語言（intermediate language）的形式出現，不基于任何一種特殊的cpu平臺，同時在生成集合時自動產生元數據(metadata)，此元數據在集合中以貨單（manifest）的形式存在，元數據可以對組件進行自我描述，通過元數據，可以知道組件有哪些類型、哪些資源。在元數據中也包含集合的版本號等。有了這樣的組件-集合，再也不會出現dll陷阱等類似的問題。所以說集合是.net的版本控制技術的基礎，集合技術的出現使得開發人員和管理人員可以在不同應用程序之間嚴格地實行版本依賴政策，因為集合可以自我描述和自我解釋。也可以實現真正的無副作用安裝。由于集合的自我描述，使得注冊表等概念將過時。在.net平臺下，所有的程序安裝將變為拷貝，嚴重的注冊表垃圾問題將不存在。在另一方面，由于集合成為能否使用的組件的最小單位，所以集合在.net的安全領域也有非常重要的作用。
下面談一下系統服務，在.net內部包含大量的基礎類，這些基礎類存在于集合體中。每一種基礎類都定義了一些.net平臺潛在的某些屬性。屬性相似的基礎類被包含到同一名空間中（namespace）。在名空間中，最底層也是最常用的名空間是系統名空間，在系統名空間中包含的類均為基類，在作用上有點象cobject類在mfc中的作用。另外，系統名空間還包括了異常情況處理、垃圾回收、控制臺輸入輸出等等一系列重要地特性。總的來說，如果想利用.net平臺的任何特性，你都需要和名字空間及其所擁有的類進行交互。對于開發人員，在這些名字空間的基礎上可以派生自己的類和名字空間。利用系統服務提供的大量服務，開發人員可以以更高的效率、更快的速度、以更好的方式開發基于internet的程序。
在整個.net框架中，從技術角度上看，最重要的概念莫過于通用語言運行時（common language runtime），以下均以clr作為其代表。如果把系統服務看成.net框架的基礎的話，那clr可以看作.net框架的核心。對于軟件開發人員而言，理解.net的關鍵之處就在于對clr地理解。對于windows開發人員來說，不論是c runtime library還是mfc還是java virtual machine都會或多或少的了解一些。實際上，windows操作系統本身就可以認為是運行時和庫的集合體。運行時和庫一起為應用程序提供服務，在一定程度上極大地節省了時間，并且有利于代碼的重用。比較com的編程模式可以更好地理解clr的編程模式，對于com而言，它的編程思想是基于類型而不是面向文件的。在這一點上，clr也是采用的這種辦法。在最早的windows編程中，當需要調用某dll的接口時，一般利用loadlibrary函數，然后再調用getprocaddress函數，隨著com的出現，cocreateinstance和queryinterface函數改變了這一切。clr也是以類型為中心的。雖然在編程模式上clr與com一樣，但在實現方式上是不一樣的。clr克服了一些com本身固有的弊端，例如類型信息格式不統一、私有類型信息不能接觸等。第一，在clr中組件的概念成為頭等類公民。在com中，表示組件的方式有很多，對象、類、動態連接庫都可以表示組件；而在clr之中組件的概念是以集合(assembily)的形式出現的，對于每一種類型，com采用128比特的uuid進行定義，而在clr中為了更好地確保唯一性，采用了128字節的公鑰和在局部范圍內是保持唯一的類型名稱來提供全球唯一表示。當一個客戶端應用程序調用某集合時，在客戶應用程序中存有一64位的公鑰hash值，從而能確保被調用的集合是正確的集合。第二，對于clr，只有一種元數據交換格式存在。在com編程中，需要在idl中定義類型信息，然后再利用一種具體的語言（c++或java）去實現。在clr中開發人員可以在任何一種語言中定義并實現該類型。第三，元數據是完全可擴展的。任何語言都可以擴展clr的類型信息。第四，在com中存在兩種類型系統，iunkown型和variant型；在clr中所有的類型都來自system.object。第五，在clr中允許出現接口的多繼承。總而言之，正如不了解com技術就無法真正了解windows一樣，理解clr對于了解.net是非常重要的。其實，從一定角度上來說，clr是com的向前的巨大飛躍。
三、.net的新特性
.net是全新的一種技術，因此，.net中也包括了很多新特性。這里只列出一些比較重要的特性。
（一）、一致的編程模式
在.net環境中，所有的應用程序都采用通用的面向對象編程模式，不再像windows環境中那樣，既有dll函數也有com對象。（二）、簡化了的編程模式
這也許是最令開發人員歡欣鼓舞的消息了，在.net環境下，由于clr的作用，在進行編程時不再需要掌握guids、iunknown、addref等令人頭疼的com知識了。
（三）、運行于多個平臺
對于任何操作平臺，只要支持.net運行時均可以運行.net應用程序。現在所有的windows平臺均可以實現這一點。在將來甚至可以運行在非windows操作系統上。
（四）、支持多語言的綜合
按照com的原理，代碼重用是建立在二進制代碼的級別上。在.net環境下，代碼重用可以建立在源碼的級別上的，也就是說，別人用c#語言寫的某個類可以直接在c++這樣的語言中使用。之所以.net有這樣的巨大威力在于.net為所有的支持.net編程方式的語言提供了一整套通用的類型系統。
（五）、自動資源管理
可以毫不夸張地說，對于所有開發人員而言最頭疼的就是內存泄露問題。在.net環境下，這個問題得到徹底解決，自動資源管理功能已經加入到clr之中。同時，由于資源回收功能的加入，在一定程度上安全性也得到了保障，諸如內存溢出攻擊等將得到有效控制。
（六）、一致的出錯處理方式
相信所有的windowssdk程序員都對windows環境下混亂的錯誤處理方式感到厭煩，win32錯誤代碼、異常情況處理、hresult等等。在.net環境下所有的程序都采用統一的錯誤處理方式---產生異常。
（七）、安全性
正如我們已經知道的一樣，.net的出現是為了迎合下一代的internet環境下的企業級計算，一般的訪問控制已經不能滿足它的要求，所以在安全性方面.net相對于windows等其他系統而言，有了更深入的改進。從裝載一個類開始，就進行確認檢查；在訪問代碼和相應資源時，又實施代碼訪問安全措施。.net提供了一整套機制來判斷角色和確認身份信息，并且能作到跨進程和機器從而確保所需的代碼在遠端沒有受到破壞。.net的安全性也深深地嵌入到clr結構中，以確保應用程序本身的安全。這些安全機制是對現有操作系統安全機制的一種質上的擴展，比較起來，.net在安全性上得到了進一步的加強。
（八）、xml和soap的引入
回憶下過去分布式應用程序的設計，過去我們設計兩層的應用程序，在此基礎上出現了諸如corba、iiop、rmi和dcom這樣的協議。人們已經熟悉了這樣的分布式系統。但是這樣的分布式系統的弊端就是靈活性差，因為這種設計方式使得應用程序固定在服務器端。而internet是個松散連接、非常分布的世界。原有的client/server結構已經過時，這樣就提出了全新的編程模式，而xml和soap能使這種模式很好地工作。在.net中xml和soap已經深深地溶入其中，并成為非常重要的組成部分。
（九）、全新的編程語言c#
隨著.net的推出，微軟也強力推出了一種新型的編程語言c#。c#象vb一樣簡單，又象c++一樣強大。在有些人的眼里，c#是java的復制品。這種說法似乎有一些道理，因為c#太像java了。但正確地說，c#絕不是java的克隆，c#的推出是微軟在研究了c、c++、java、modula2、smalltalk等大量語言的基礎上推出的語言，比較起java來，c#的最大不同之處在于它更接近c++，同時c#也吸收了大量新的概念，例如c#是面向組件的語言，c#能作到與xml協議的最大程度的融合。同時，c#在編譯方式上與java又很不一樣。c#的推出與.net是密切相關的。
四、.net與j2ee的比較
在計算機世界里，新技術不斷地出現。以下就sun公司推出的j2ee和微軟的.net在面向下一代企業計算方面比較一番。
j2ee平臺提供了一個基于組件的方法，來設計、開發、裝配及部署企業應用程序。j2ee平臺提供了多層的分布式應用模型、組件重用、一致化的安全模型以及靈活的事務控制。同時保證您的平臺獨立的、基于組件的j2ee解決方案不會被束縛在任何一個廠商的產品和api上。通過以上的論述我們可以看到在設計新技術的出發點上應該說.net和j2ee是非常相似的。但是這兩種技術在實現方法和具體的實現技術上都有很大甚至對立的區別點。
首先需要指明的是.net決不是簡單的改進型的windows操作系統。因為按照微軟的設計思想，任何一個操作平臺只要安裝了clr就能夠運行.net程序。
1， 在開發語言上，.net的支持面是比較廣的，c++、vb、c#、perl、cobol等等均得到支持，開發人員可以很容易找到適合自己的語言。而j2ee只支持java語言。這就是說j2ee在語言的選擇面上是比較窄的。當然，c#是.net支持的最重要的一種語言，相對于java而言，c#是支持jit(just-in-time)編譯方式的，而java是基于解釋方式的。同時微軟為不同的平臺環境提供了不同的jit編譯方式。對于類似于windows ce這樣的移動計算環境，微軟提供了壓縮的.net框架，相應的也提供了econojit（經濟型編譯器）。在一般的桌面環境下，微軟提供了標準的編譯器。另一方面，c#將成為一種工業標準，因為ecma（歐洲計算機制造商協會）正在接納c#；而java語言只是sun公司提出來的。
2， j2ee支持java、ejb，而.net支持xml/soap。從標準的開放性上來說，xml/soap要好于前者。xml由w3c組織提出，得到眾多廠家的支持，是下一代internet上內容表示的標準，xml能夠有效地表達網絡上的各種知識，為信息的交換和計算提供新的載體。xml相對于網絡計算的作用，完全可以與計算機起步階段ascii碼的作用相提并論。xml也可以說是網絡信息的標準代碼，它表示的不是符號信息，而是知識化的塊狀內容。這種標準語言雖然不是程序設計語言，但是它代表的卻是下一代網絡上互操作的光明前景。說到這里，不由得讓人想起了人們"當年"對 java 的狂熱。確實，java有著非常誘人的初衷，讓許多人能夠在這樣的一種理想的感召下為想象中的各種系統之間的互操作能力而投入積極的開發中。但是實際上，java既沒有成為人們想象中的成功的商業計算工具，也并沒有實質上的技術進步。java試圖從統一計算平臺的角度來實現互操作，但是這可能永遠都是一個夢想。真正能夠互操作的，只能是標準和通用的數據描述語言。而soap協議本身也是由微軟和ibm這樣的商業巨頭聯合推出開發。這一切都表明.net技術標準的開放性是不錯的。
3， .net的soap協議能夠保證一個平臺上的組件能夠與.net平臺上的組件進行信息的交換。
4， 最重要的一點是，在現有的條件下，各種各樣所謂的跨平臺、“編譯一次，多處運行”等口號只是商業炒做。java的首席設計師james goslin在談到這個問題時曾經表達過這樣的看法，所謂的“編譯一次，多處運行”口號只是一種美好的想法。這就是說，基于某一種開發平臺進行開發是不可避免的，假如你基于ibm公司的websphere利用java開發商業程序的話，基本上就固定在這個平臺上了。java所號稱的100%純的口號其實不是這樣；當然，c#也是如此。
5， 在.net平臺上開發程序的一個重要好處在于可以實現真正的“代碼重用”。因為在設計.net平臺時，一個重要的思想就是運行時和具體的語言分開。所有的資源管理、內存分配、變量類型等均由運行時處理，這樣的話，用c#寫的類直接就可以用在c/c++程序中。這樣的話，只要基于.net平臺，過去的程序不會因為要采用新型語言而做非常大的修改。而在j2ee平臺上，java就是java，它將運行時和具體的語言混在一起。
總而言之，j2ee和.net各有各的優點和缺點。二者都是非常優秀的開發企業計算軟件的優秀平臺。但就象不同的人有不同的嗜好一樣，在未來的開發中，還是要根據自己的具體需要而確定具體的應用平臺。
五、對.net的幾點疑問
通過上述的分析，我們可以感覺到.net確實是一場技術上的革命。但是經過研究后還是會對.net產生幾點疑問。
1， 是真正的跨平臺嗎？
按照微軟的說法，任何一個操作平臺只要裝載了通用語言運行時（clr）就能作到“寫一次、編譯一次、任何地點均可運行”。也就是說，clr對于.net程序是非常重要的。雖然微軟的研究開發中心正在開發clr模板，從而達到這樣的要求。但是至少未來出現的第一版.net不會有這種功能，它只是支持過去的windows平臺。就算將來融合了clr模板，能否作到跨平臺也是個疑問。
2， com（組件對象模型技術）真消失了嗎？
在2000年的pdc（開發者大會）上，微軟曾表示令人頭疼的com編程模式將徹底消失，取而帶之的將是clr，iunknown等接口將不會出現。對此，不能太樂觀，要知道com是windows的基礎，并且在上面也談了clr和com技術的關系。應該說com沒有消失，而是有了非常大的進步（至少在編程方法上）。
3， 代碼級的多語言交互能真正做到嗎？
對于像visual java、visual basic、c#這樣的開發受管理的代碼（managed code）的語言可以實現多語言交互是可以理解的。但問題是如何與c/c++這樣的本身功能非常強大，指針的應用非常廣的語言真正做到代碼重用哪？
六、后序
.net作為一種全新的革命性的技術的推出是令人興奮的。可以相信，隨著.net的正式應用的到來，它將極大的改變我們的開發模式。作為軟件開發人員來說，.net的出現將給我們帶來更大的機遇與挑戰。與其臨淵羨魚不如退而結網。狼終究還是要進來的，我們只有從現在開始就作好一切準備才能找到最適合自己的軟件開發之路，才能在技術上不受制于人。
參考資料：
http://www.microsoft.com/net/whitepaper.asp
http://msdn.microsoft.com/msdnmag
http://java.oreilly.com/
