 |
VB.NET公共運(yùn)行時(shí)的環(huán)境 |
 |
迄今為止，業(yè)界對(duì)VB.NET討論得最多的特色或許就是CLR。VB.NET運(yùn)行在CLR之上，正是CLR為VB.NET帶來(lái)了許多關(guān)鍵的新特色（包括缺點(diǎn)在內(nèi)）。例如，CLR使得VB.NET支持跨語(yǔ)言的繼承以及自由線程。
在VB6中，分布式VB程序要求有VB運(yùn)行時(shí)庫(kù)msvbvm60.dll支持，即該運(yùn)行時(shí)庫(kù)必須隨同應(yīng)用一起分發(fā)。其他許多語(yǔ)言，比如C++和Java，也有類(lèi)似的要求。在.NET中，所有Visual Studio語(yǔ)言共享同樣的運(yùn)行時(shí)環(huán)境CLR。改用CLR帶來(lái)了幾個(gè)重要的結(jié)果：現(xiàn)在所有Visual Studio語(yǔ)言都共用同樣的IDE、同樣的窗體引擎、同樣的異常處理機(jī)制，等等。它意味著Visual Basic在很大程度上已經(jīng)可以和.NET的其他語(yǔ)言相提并論，如C#等。然而，對(duì)于CLR的異議仍舊存在，VB業(yè)界仍在激勵(lì)地爭(zhēng)辯它地價(jià)值。
不管應(yīng)用是用VB、C#還是其他.NET語(yǔ)言編寫(xiě)，所有VS.NET代碼都是編譯成中間語(yǔ)言（Intermediate Language，IL）。當(dāng)應(yīng)用運(yùn)行時(shí)，一個(gè)實(shí)時(shí)編譯器（just-in-time compiler，或稱為JIT）就把IL代碼編譯成機(jī)器語(yǔ)言。在理論上，它意味著為非Windows的平臺(tái)構(gòu)造.NET運(yùn)行環(huán)境是可能的，但目前還沒(méi)有出現(xiàn)有關(guān)這類(lèi)系統(tǒng)的正式消息。IL有一個(gè)缺點(diǎn)：正如VB在5.0以前的版本，IL代碼對(duì)于類(lèi)似的反向編譯工程很敏感。由于存在這種可能性，許多開(kāi)發(fā)者對(duì)于.NET框架的整體安全性抱有懷疑。
對(duì)CLR進(jìn)行優(yōu)化影響IL層次上的代碼，它使得所有使用CLR的語(yǔ)言受益。然而，對(duì)于特定語(yǔ)言的優(yōu)化涉及到如何把代碼編譯成IL代碼，它根據(jù)特定語(yǔ)言的語(yǔ)法進(jìn)行。因此，.NET各種語(yǔ)言之間存在一定的性能差異是必然的。但不管如何，從整體上來(lái)看這仍舊是好事，例如CLR為VB帶來(lái)了和C#一樣的調(diào)試和分析工具——之所以能夠如此，是因?yàn)樗鼈兌际褂靡粯拥墓ぞ摺?
CLR提供了前所未有的跨語(yǔ)言集成能力，其中包括跨語(yǔ)言繼承代碼的能力。所有使用CLR的語(yǔ)言都使用一個(gè)公共類(lèi)型系統(tǒng)（Common Type System），它使得開(kāi)發(fā)那些運(yùn)用多種語(yǔ)言的應(yīng)用變得更為容易。
在CLR之內(nèi)運(yùn)行的代碼稱為“受管理的代碼”（Managed Code），受管理代碼所使用的內(nèi)存由CLR全面控制。受管理的代碼有著許多優(yōu)點(diǎn)，包括交叉語(yǔ)言集成、跨語(yǔ)言異常控制以及一個(gè)組件交互的簡(jiǎn)化模型。Visual Basic.NET只能以受管理代碼方式運(yùn)行，與此相對(duì)應(yīng)，C#卻具有將代碼轉(zhuǎn)入非受管理方式運(yùn)行的能力（運(yùn)行在CLR之外），比如執(zhí)行指針處理之類(lèi)的操作。這是VB.NET不能與C#相提并論的地方之一。然而，這種能力的是否重要，對(duì)于不同的人、不同的用途來(lái)說(shuō)都有所不同。
由CLR導(dǎo)致的體系上的不同不僅僅是跨語(yǔ)言繼承、共享功能和受管理代碼，它還有更深刻的意義。Visual Studio.NET的底層體系不再是COM；另外，VB.NET中所有東西都是對(duì)象，甚至連字符串也一樣。由于這些原因以及其他許多原因，Microsoft改變了底層體系管理對(duì)象的方法。COM系統(tǒng)通過(guò)引用計(jì)數(shù)方式管理對(duì)象，每當(dāng)對(duì)象被引用時(shí)，引用計(jì)數(shù)就增加。當(dāng)對(duì)象引用超出作用范圍或者被釋放時(shí)，計(jì)數(shù)器的值就減少；一旦引用計(jì)數(shù)為0，對(duì)象就被釋放。Microsoft聲稱.NET體系中的引用計(jì)數(shù)開(kāi)銷(xiāo)實(shí)在太大，使得.NET采用引用計(jì)數(shù)不再合適，因此它就放棄了引用計(jì)數(shù)，改用垃圾回收（Garbage Collection）。
大約40年前，John McCarthy設(shè)計(jì)了LISP語(yǔ)言，它是可考證的第一種編程語(yǔ)言。LISP運(yùn)行時(shí)不斷地分配和釋放大量的小塊內(nèi)存，由于那時(shí)的計(jì)算機(jī)內(nèi)存遠(yuǎn)遠(yuǎn)沒(méi)有現(xiàn)在這么龐大，因此早期的LISP用戶很快感到內(nèi)存不足，同時(shí)許多不再使用的內(nèi)存卻未能利用起來(lái)。為了解決這個(gè)問(wèn)題，McCarthy于1959年第一次提出了垃圾回收的思想。
在一個(gè)真正面向?qū)ο蟮南到y(tǒng)中，垃圾回收機(jī)制能夠很好地滿足分配和釋放大量小塊內(nèi)存的需要。因此，Microsoft在VS.NET中重新實(shí)現(xiàn)了垃圾回收機(jī)制。
CLR垃圾回收器（CLR Garbage Collector）的主要任務(wù)就是監(jiān)視程序使用的資源，當(dāng)可用資源達(dá)到某個(gè)確定的極限時(shí)查找不再使用的對(duì)象，如發(fā)現(xiàn)有這類(lèi)對(duì)象存在則釋放它們所占用的資源。垃圾回收的一個(gè)很大的優(yōu)點(diǎn)是程序員無(wú)需再為大多數(shù)常見(jiàn)的循環(huán)引用擔(dān)心。在循環(huán)引用情形下，子對(duì)象擁有對(duì)父對(duì)象的引用，同時(shí)父對(duì)象又擁有對(duì)子對(duì)象的引用。在引用計(jì)數(shù)模式下，循環(huán)引用阻止了系統(tǒng)釋放和拆除任意一個(gè)對(duì)象。然而，垃圾回收器能夠找出這類(lèi)循環(huán)引用并拆除它們。垃圾回收機(jī)制同時(shí)也意味著，當(dāng)對(duì)象的最后一個(gè)引用被釋放時(shí)，對(duì)象并不一定立即被拆除。
采用垃圾回收機(jī)制的一個(gè)后果是：我們不能再希望類(lèi)的Terminate事件總是適時(shí)觸發(fā)。事實(shí)上，如果線程被阻塞的話，Terminate事件可能完全不會(huì)觸發(fā)。這就是所謂的“非確定的結(jié)束”（non-deterministic finalization），而COM提供的則是“確定的結(jié)束”。由于缺乏“確定的結(jié)束”，再加上因?yàn)槔厥掌髦匦陆M織和整理內(nèi)存導(dǎo)致不能運(yùn)用指針，新聞組中出現(xiàn)了對(duì)該問(wèn)題激烈的爭(zhēng)論：有些人憎恨這些新的限制，因?yàn)樗麄円蕾囉凇按_定的結(jié)束”；有些人覺(jué)得無(wú)關(guān)緊要，因?yàn)樗麄儾⒉灰蕾囉赥erminate事件。
從引用計(jì)數(shù)轉(zhuǎn)變到垃圾回收僅僅是Visual Studio.NET底層體系不再是COM這一變化的諸多必然結(jié)果之一。雖然VB.NET之內(nèi)仍舊可以使用COM對(duì)象，但這些對(duì)象必須通過(guò)封裝（Wrapper）才能訪問(wèn)。任何時(shí)候，封裝都意味著性能的降低，甚至還有可能導(dǎo)致對(duì)象行為的異常。如果要遷移一個(gè)大量使用COM對(duì)象的工程，你必須認(rèn)真地進(jìn)行計(jì)劃和測(cè)試，應(yīng)用程序的某些部分可能還需要重新構(gòu)造。
七、面向Web的支持
除了Windows Forms新引擎之外，.NET還包含了一個(gè)專門(mén)為構(gòu)造Web窗體設(shè)計(jì)的窗體引擎，稱為Web Forms。這個(gè)引擎的目標(biāo)在于讓用戶能夠象創(chuàng)建傳統(tǒng)Windows桌面應(yīng)用的窗體一樣方便地創(chuàng)建Web窗體。Web Forms是一種ASP.NET技術(shù)，通過(guò)它我們可以使用熟悉的RAD（快速程序開(kāi)發(fā)）工具構(gòu)造出帶有執(zhí)行代碼的窗體。不過(guò)，窗體中的ASP.NET代碼以編譯方式在服務(wù)器端運(yùn)行，經(jīng)過(guò)處理后把結(jié)果HTML發(fā)送給支持HTML 3.2的瀏覽器。
客戶端事件數(shù)據(jù)由底層框架截獲并發(fā)送到服務(wù)器。這意味著應(yīng)用界面不再受瀏覽器類(lèi)型的約束，意味著有大量UI工具可供使用，意味著用戶可以充分發(fā)揮現(xiàn)有的窗體制作技巧。如果應(yīng)用沒(méi)有必要做到瀏覽器中立，那么它就可以利用IE瀏覽器的各種特色。有了Web Forms，我們將能夠更輕松地為那些具有Web功能的應(yīng)用構(gòu)造出更好、更豐富的用戶界面。
VB.NET中另外一個(gè)面向Web的重要特色是Web服務(wù)。在Microsoft的宣傳中，Web服務(wù)被推崇為之所以要采用.NET技術(shù)的重要理由之一。事實(shí)上，從根本上來(lái)說(shuō)Web服務(wù)是一種類(lèi)似COM的、通過(guò)Web服務(wù)器和標(biāo)準(zhǔn)協(xié)議發(fā)布的對(duì)象。當(dāng)然，Web服務(wù)并不是嚴(yán)格意義上的COM對(duì)象，但兩者作用方式類(lèi)似。Microsoft期待著各類(lèi)公司都以Web服務(wù)方式提供服務(wù)，期待著未來(lái)創(chuàng)建應(yīng)用時(shí)只需簡(jiǎn)單地“粘合”各種服務(wù)，就象今天借助Office和支持VBA的應(yīng)用通過(guò)VBA構(gòu)造新應(yīng)用一樣簡(jiǎn)單快捷。
從Microsoft PDC（Professional Developers Conference，專業(yè)開(kāi)發(fā)者大會(huì)）的一個(gè)演示中，我們可以看出Microsoft希望開(kāi)發(fā)者如何粘合各種Web服務(wù)。在這個(gè)演示中，一個(gè)假想的醫(yī)生以Web服務(wù)形式發(fā)布其時(shí)間表，示范如何通過(guò)Web用智能電話和醫(yī)生訂立約會(huì)。Visual Basic.NET還允許查詢服務(wù)器，提取服務(wù)器支持的所有服務(wù)的元數(shù)據(jù)。Web服務(wù)描繪了Microsoft野心勃勃的戰(zhàn)略，然而，唯有時(shí)間才能告訴我們Microsoft是否在大范圍推廣Web服務(wù)上取得了成功。但不管如何，這個(gè)想法本身看來(lái)有著美好的前途。
為了減少與封裝和分發(fā)應(yīng)用有關(guān)的問(wèn)題，如令人畏懼的DLL Hell問(wèn)題（在共享DLL的應(yīng)用之間，由于一個(gè)應(yīng)用的升級(jí)而導(dǎo)致另一個(gè)應(yīng)用無(wú)法正常運(yùn)行的情況），Microsoft作出了種種努力，它同樣也帶來(lái)了美好的希望。所有.NET應(yīng)用都封裝為程序集（Assembly）。程序集包含了描述各種運(yùn)行需求的元數(shù)據(jù)。這種元數(shù)據(jù)稱為manifest，其中包括：程序集的標(biāo)識(shí)信息（名稱，版本等），列出了所有文件依賴關(guān)系以及文件位置和文件版本的文件清單，外部依賴信息（帶有描述程序集必須用到、但開(kāi)發(fā)者沒(méi)有自己創(chuàng)建的DLL以及其他資源的數(shù)據(jù)）。程序集是通過(guò)manifest自我描述的，因此.NET應(yīng)用的運(yùn)行并不需要修改注冊(cè)表。換句話說(shuō)，.NET應(yīng)用不再要求注冊(cè)組件。在最理想的情況下，客戶機(jī)器上已經(jīng)有了.NET運(yùn)行環(huán)境，部署一個(gè)復(fù)雜的應(yīng)用簡(jiǎn)單到只需復(fù)制一個(gè)文件夾到目標(biāo)機(jī)器。使用程序集的另外一個(gè)優(yōu)點(diǎn)是：不同的應(yīng)用可以擁有同一DLL的不同版本，所有這些應(yīng)用都互不干涉地在同一臺(tái)機(jī)器上運(yùn)行。如果它能夠按照預(yù)期那樣獲得成功，DLL Hell和可怕的版本問(wèn)題都將成為歷史。
Visual Basic.NET代表著VB的一次重大飛躍。盡管如此，把VB.NET看成是一種有著熟悉語(yǔ)法的新語(yǔ)言而不是對(duì)舊語(yǔ)言的簡(jiǎn)單升級(jí)或許是對(duì)待VB.NET較為正確的心態(tài)．
|
| 作者：未知 | 文章來(lái)源：未知 | 更新時(shí)間：2008-1-15 16:40:33
|
|
 |
 |
最新文章 |
|
|
 |
