細說.Net開發(fā)中的Visual Basic.Net(2)_.Net教程

推薦：怎么在ASP.NET中使用SmtpMail發(fā)送郵件
在ASP中，就可以通過調(diào)用CDONTS組件發(fā)送簡單郵件，在ASP.NET中，自然也可以。不同的是，.Net Framework中，將這一組件封裝到了System.Web.Mail命名空間中。 一個典型的郵件發(fā)送程序如下： ＜%@ Import Namespace=System.Web.Mail %＞ ＜script runat=server

易于反編譯的中間語言

無論你用VB、C#或其它.NET語言編寫應用程序，VS.NET代碼都編譯成為中間語言(IL)。當應用程序運行時，一個即時編譯器(JITter)處理IL代碼并把它編譯成為機器語言。這意味著在理論上可能為Windows以外的平臺創(chuàng)建.NET運行庫，但現(xiàn)在關于類似的事情還沒有任何官方消息。中間語言的一個缺陷是：它像VB5以前的VB版本一樣，容易被反編譯。這種可能性使許多開發(fā)者普遍地質(zhì)疑.NET架構的安全性。

CLR在IL層次內(nèi)外影響代碼，對它的修改將使所有使用CLR的語言受益。然而，語言只是和代碼如何被解釋為IL有關，對特定語言的優(yōu)化可以根據(jù)特定語言的語法來編寫，這樣在技術上就可能使.NET語言之間的性能差別很小。不管怎樣，大體上藍圖是美好的。例如，CLR使VB的調(diào)試和監(jiān)測工具和C#的相應工具相當，它做到了這一點因為它們本來就是相同的工具。

CLR提供不平行的跨語言集成，包括跨語言繼承代碼的能力。所有使用CLR的語言共享一個通用類型系統(tǒng)，它使使用多種語言開發(fā)應用程序變得更簡單。我不喜歡把 C API 聲明翻譯成VB里可以使用的形式，所以我很贊賞通用類型系統(tǒng)帶來的好處。

在CLR中運行的代碼被稱為被管理代碼，被管理代碼使用的內(nèi)存完全由CLR來控制。被管理代碼帶來很多好處，包括跨語言集成、跨語言異常處理和簡化的部件相互作用模型。Visual Basic被限制為只能以被管理代碼的方式工作，然而C#擁有跳到非被管理代碼的能力(執(zhí)行到運行庫之外)，并能做像指針操作這類事情。這是VB和C#不同等的情況之一。這種能力到底有多重要取決于你想干什么。

CLR造成的體系結構差別要比跨語言集成、共享功能和被管理代碼等深刻。首先，Visual Studio.NET的支撐結構不是 COM。另外，VB.NET里的所有東西，甚至字符串都是對象。因為這些和其它一些原因，Microsoft改變了支撐結構處理對象的方式。COM實現(xiàn)了一個引用計數(shù)方案，這樣每次引用一個對象時，計數(shù)器遞增。當一個對象引用超出作用域或被釋放時，計數(shù)器遞減，當引用計數(shù)減少到零時就終止這個對象。Microsoft聲稱在.NET架構下引用計數(shù)的開銷太大，以至于不能在 .NET中實現(xiàn)它，所以它放棄了引用計數(shù)轉(zhuǎn)而使用垃圾收集。

垃圾收集需要新體系結構

CLR垃圾收集器主要是監(jiān)視一個程序的資源，當可用資源達到確定的閾值時尋找無用的對象，并在發(fā)現(xiàn)它們的時候清除這些對象。垃圾收集的一大好處就是你不再需要擔心大多數(shù)普通的循環(huán)引用，即子對象引用了父對象，然后父對象又引用了子對象。在引用計數(shù)方案下，循環(huán)引用使兩個對象都不能被釋放和清除。然而，垃圾收集器會發(fā)現(xiàn)循環(huán)引用并清除它們。這也意味著釋放對象的最后一個引用時不再需要立即清除對象。

垃圾收集的一個后果是：你再也不能指望一個類的 Terminate 事件能在適當?shù)臅r機發(fā)出。實際上，如果線程被阻塞，可能根本就不會發(fā)出 Terminate 事件。和COM提供的確定化終止相反，它被稱為不確定的終止。缺乏確定化終止，以及因為垃圾收集器重新安排并壓縮內(nèi)存從而不能使用指針的事實，在新聞組里激發(fā)了一波激烈的辯論。我想這些新限制可能會令你痛恨，因為你要依靠確定化終止;也可能你漠不關心，因為你不依賴 Terminate 事件。垃圾收集并不是萬靈藥，實現(xiàn)弱引用依然需要做一些考慮。

從引用計數(shù)到垃圾收集只是 Visual Studio.NET 的支撐結構不是 COM 這個事實的表象之一。你能在VB.NET中使用COM對象，比如說ActiveX服務器或ActiveX控件。然而，你必須通過包裝訪問這些對象。任何時候聽到“包裝”這個術語，你應該明白你面對著性能損失，并且對象的行為可能有所不同。如果當計劃移植一個使用了大量COM對象的工程，就需要認真地測試和計劃，可能需要重新規(guī)劃應用程序的結構才能移植成功。坦率地說，你要有遭受挫折的準備。還記得從VBX遷移到 OCX的過程嗎?我記得，我的精神病醫(yī)生也記得。我很快就要再去看他了 ;-)

語言本身的變化要遠遠超過體系結構的變化。大部分改變確有道理，但我并不認為所有的改變都是如此。以前版本的VB允許你以很多方法來做很多事，以至于統(tǒng)一的編碼標準要么不存在要么就很難強加于人。Microsoft對VB做了大量的改變?yōu)榈木褪?ldquo;清晰”這種語言。很多情況下，原來你有好幾種方法做一件事，現(xiàn)在就只有一種了。Billy Hollis 提供了語法變化的詳細列表，包括廢棄的關鍵字列表，但有些東西需要在這里重復一下。

首先，向過程參數(shù)傳遞數(shù)據(jù)的默認方法由引用(ByRef)變成了傳值(ByVal)。這個改變主要是因為引用要比傳值的風險大得多。它的風險主要是調(diào)用過程中的數(shù)據(jù)可能被無意中篡改。你仍然能通過引用傳遞數(shù)據(jù)，但這一改變使你需要修改新的默認調(diào)用方法來使用引用。

其次，Set 語句消失了。在 VB.NET 里如果你需要向變量傳遞一個對象引用，所需要的只是一個等號，對象被視為同其它值一樣。這很酷，但也有副作用：默認屬性消失了。例如，你不再能用這種方式引用一個屬性：

以下是引用片段：Text1 = "What, me worry?"

作為替代，你必須顯式地引用屬性：

以下是引用片段：Text1.Text = "What, me worry?"

也許一眼看來不需要這種改變，但確實必須去掉默認屬性。例如，假定你有一個叫objFoo的對象變量，不用Set語句，下面的語句所設置的引用就產(chǎn)生了歧義性：

以下是引用片段：objFoo = Text1

這條語句是應該設置到Text1的引用，還是以Text1的Text屬性來填充objFoo?你不能確定，編譯器也不能。拋棄Set語句同時要求拋棄默認屬性。

有一個改變我不喜歡：你不再能在不同的作用域里聲明Property Get和Property Set過程。注意 VB.NET 沒有 Property Let 語句：對象和數(shù)值都用 Property Set。這意味著你不能用一個 Friend Property Let 過程來對應一個 Public Property Get。用VB建立組件時可能會有麻煩。許多組件開發(fā)者創(chuàng)建 Friend Property Set 過程以使他們的應用程序能改變一個值，但提供 Public Property Get 過程以使他們的客戶程序能取回值。我希望我能為這個改變找到一個合適的理由，可是我找不到。

分享：談.Net和Java的socket機制比較
socket是基于TCP和UDP協(xié)議的高層接口，定義了收發(fā)數(shù)據(jù)的格式。Java的TCP服務中使用的Socket是一種流機制，即對于編程人員來說，處理socket只需要從Socket中獲取流，然后可以像處理本地流一樣來進行數(shù)據(jù)的收發(fā)。 例如： DataOutputStream outToClient ＝new D