微軟 .NET

來源:互聯網
上載者:User
微軟 關鍵詞:.NET、XML(可擴充標記性語言)、SOAP(簡易物件存取通訊協定 (SOAP))、WindowsDNA、集合(assembly)、通用語言運行時(CLR)、IL(中繼語言)、中繼資料(metadata)、名空間(namespace)、C#

一、 序言

什麼是.Net?不同的人有不同的解釋方式。有人認為.NET是一種全新的下一代可視化開發環境;有人認為.NET是一種新的針對Internet時代的開發語言---C#;有人認為它是基於XML(可擴充標記性語言)和SOAP(簡易物件存取通訊協定 (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試圖從統一計算平台的角度來實現互操作,但是這可能永遠都是一個夢想。真正能夠互操作的,只能是標準和通用的資料描述語言 (Data Description Language)。而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/


相關文章

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。