VisualBasic的未來
一個版本中將出現的WebForms(Web表單),Webservices(Web服務)和語言的改進
本文讀者是已經熟悉了VisualBasic的使用者。
概述:下一個版本的MicrosoftVisualBasic主要有以下三個方面的改進：WebForms、Webservices和物件導向的語法方面的改進。 WebForms使得經驗豐富的VisualBasic使用者可以像現在編寫單機程式一樣簡單地開發網頁應用程式。透過SOAP介面,Webservices讓你在可以連網的任何地方配置你所設計的元件。另外，幾個在物件導向的語言方面的關鍵性的改進使得VisualBasic的程式碼象C 一樣具有靈活性，這幾方面的改進包括繼承性、多態性和重載。有關這方面的內容可以參考SteveBallmer的“VBITSkeynoteonthenextgenerationofVisualBasic”
isualBasic已經經歷了許多次的改進。然而從它誕生以來，我就一直喜歡它的一點是：就它的核心而言，你仍然可以像1991年一樣的編寫你的程式。當然，和那時相比它的軟體包已經有了很大的增強，但是這些改進一般是補充性的，並沒有模糊作為編程工具本身俱有的目的，這個目的就是：使VisualBasic能更簡單快捷地用於設計、編寫和調試出優秀的物件導向的應用程式。
目前使用的VisualBasic6.0版本引進WebClasses作為一種簡化手段，用於配置健壯的網路導向的應用程式。事實上，WebClasses提供了大量的途徑可以透過常見的工具把程式移植到網路上。 （關於VisualBasic6.0在網絡下的可伸縮性的詳盡討論可以參見TedPattison的”AdvancedBasicscolumn”(MicrosoftInternetDeveloper於1999年十月出版發行)
我最近有機會了解了下一個版本的VisualBasic計劃採取的一些新的改進。其中主要的改進是在儲存容量方面，開發者可以使用的儲存容量擴大了三倍。下一個版本的VisualBasic計畫將採用VisualStudio®環境中稱為WebForms的特性。 WebForms代表著一種全新的組件化的網路解決方案。 Webservices將成為一種新的基於xml的方案，它透過標準的網路協定發佈中間層的事件處理功能。同時，VisualBasic語言將包括一些開發者長期以來一直要求的結構，這使得VisualBasic符合那些C 和java使用者所熟悉的物件導向的程式設計習慣。
在下一個版本的VisualBasic的測試版中，這些改進將會被公佈。在這裡我會給出一些程式碼片段，但不是完整的方案。那現在還有什麼好擔心的呢？很簡單，只要你決心利用這些新的功能，你現在就可以透過這些特定的方法來設計你的程序，得到最好的實踐練習，從而順利地幫助你過渡到下一個版本的VisualBasic。即使你不這麼做，只要你按照我在本文末所提出的原則去組織你將來的程序，你也不會有什麼損失的。
VisualStudioWebForms
VisualBasic的下一個版本將是VisualStudio開發環境的一部分，並且很可能會為網頁開發者引入WebForm這個新的概念。引進WebForm概念的目的是為了擴展VisualBasic的隨機存取功能，從而使VisualBasic可以應用於影響日益廣泛的網路程式的編寫。使用VisualStudio中的任何一種語言的開發者都可以共用這個VisualStudioWebForms。
一個WebForms頁包含兩個部分：實作WebForms頁視覺化介面的一個HTML檔案和處理WebForms頁事件的來源檔。既然目前有三分之一基於VisualBasic環境的開發是面向網絡，Microsoft計劃進一步增強這方面的功能。在下一個版本的VisualBasic中，你可以像現在使用VisualBasic產生表單一樣設計WebForms。你將擁有一個Web控制工具箱。你可以直接把控制項拖放到HTML編輯器中使用，只需要設定它們的特性，寫一些適當的程式碼即可。 (見Figure1)。總而言之，你可以像你使用VisualBasic產生表單一樣來做這些工作。你將擁有完全符合IntelliSense®、WYSIWYG格式的表單設計和編譯過的程式碼。所以只要你知道如何使用VisualBasic編寫應用程序，WebForms就可以讓你成為一個網頁開發者而不用絲毫改變你的工作方式。
Figure1BuildingaWebForminFourSteps
WebForms在伺服器上運行，只把HTML格式的表單傳給使用者。正如ActiveServerPage(asp)一樣，它既不是特定的瀏覽器，當然也不是基於WebForm的應用程式；但整個過程也是在伺服器上運行。事實上，你正在運行一個程序，它為遠端使用者產生HTML3.2格式的介面。跟ASP網頁不同，這些程式碼是編譯運行而不是解釋的，所以運行速度有明顯的提升。
設計WebForms的目的是為了同時獲得ASP和WebClass兩者最好的功能。你可以使用VisualStudio家族中的任一種語言來產生WebForms。所以，你可以使用你所掌握的知識來編寫高效的、面向伺服器的網頁應用程式。
Webservices
Webservices是VisualStudio開發工具系統採取的第二大改進。就核心而言，一個Webservices就是一個透過標準的網路協定發布的中間層的事件處理函數。既然它們使用HTTP作為傳送機制(見Figure2)，所以可以透過防火牆進行通訊。只要合適地分配URL，你可以簡單地在一個網路應用程式中建構多種Webservices。在程式運行時，所有這些內部構件之間的呼叫都會自動打包，透過XML介面進行呼叫。開發者可以在任何平台上、使用任何語言編寫和使用Webservices。如果你需要保密，你可以使用SecureSocketLayer(SSL)或標準校檢技術。
Figure2WebservicesArchitecture
如果你對這些聽起來開始覺得有點熟悉了，那是一個很好的開始。用於元件之間傳送資料的機制是SOAP，也就是簡單物件授權協議。 DonBox在2000年三月出版的MSDN™Magazine中詳細的介紹了SOAP。
所有這些新的特性都是為了讓網路程式開發者可以利用已存在的、可再次使用的Webservices進行組合，從而可以更快的編寫他們的程序，而不用每次都重頭來編寫它們。這將帶來程式碼提供者和程式開發者的新時代。
使用下一個版本的VisualBasic,你很快就可以把一個具體項目中的函數以Webservice的形式發布和實現。你也許很熟悉把一個VisualBasic的類別定義為public的過程。在下一個版本的VisualBasic中將會有一個新的標誌，暫時叫作webpublic。這意味著程式將作為Webservice發布。它不僅可以透過COM介面為需要它的當地專案所用，而且可以為任何引用了它的URL位址的網路程式服務。正如你可以把引用加入到一個新專案中的公開物件一樣，你也可以把引用加到網路程式中，然後像使用當地程式一樣使用它。
當然，運作機制是有些不同的。 VisualBasic能夠透過COM介面對當地物件解析參考。當你加入一個網路服務的參考到你的應用程式時，遠端物件將自動產生介面的定義，並使用SOAP協定傳送到VisualStudio開發環境中。雖然這些將以XML形式產生，但你不用自己做任何連接的工作。 VisualBasic將為你自動處理它。在接收到介面定義以後，你就可以使用IntelliSense，就像你已經寫了引用該物件的程式碼一樣。
這有一個簡單的例子。在某些場合下，你也許想寫這個叫Seahawks的函數，它可能和下面這些程式碼有點類似：
PublicFunctionSeahawks(ByValopponentAsString)AsString
Seahawks="lose"
EndFunction
如果你建構的專案中包含了這個函數，VisualBasic會自動產生關於這個函數的XML格式的描述，並把它發佈到網路上。
<?xmlversion='1.0'?>
<methodshref='http://julian/Football/Teams'>
<methodname='Seahawks'href='Seahawks'>
<request>
<paramdt='string'>opponent</param>
</request>
<responsedt='string'/>
</method>
</methods>
這個XML檔案將用於描述Seahawks函數。如果你使用的是VisualStudio開發環境，你就可以把任何已經發佈的Webservice直接拖放到應用程式中，建立一個新類別。如果你想要呼叫Internet網路上任何地方的Webservice，你只需要建立包含Webservice的類別的一個實例，然後就可以呼叫它的已發佈的方法。
當Seahawks函數被呼叫時，它會透過XML訊息包自動通訊。如果你使用的是Microsoft®InternetExplorer5.0(包含了XML支援)，你可以在你的瀏覽器中試運行該函數。你也可以如下一樣使用URL位址呼叫該函數：
http://julian/webservice1/component1.methods/Seahawks?opponent=Miami
它將傳回如下XML格式的資料：
<?xmlversion="1.0"?>
<Response>lose</Response>
為了方便Webservices的開發，VisualBasic將引入一個新的物件類型，即WebService。你可以像現在創建一個當地的DLL檔案一樣簡單地設計和發布你的WebService到遠端服務。
語言上的改進
長期以來，在喜歡VisualBasic的程式開發者和喜歡另外一些更「複雜」的語言的程式設計師之間的關係一直都很緊張。我不只一次的為我所最愛的程式語言反駁諸如」玩具語言」之類的控訴，他們認為VisualBasic缺乏OOP的特徵。
好，那猜猜發生了什麼事？下一個版本的VisualBasic將最終結束他們的抱怨。 Microsoft計畫加入物件導向程式設計的三大特性：繼承性、多態性與重載。這還不是所有！另外一些結構，包括結構化的錯誤處理和瀏覽也將被引入VisualBasic語言。
繼承性的特性允許你設計一個基類，然後寫一些派生類，它們繼承基類的功能，這樣做可以節約時間，並提高程式的可重用性。例如，你寫了一個名叫BaseClass的基底類，它有一個函數：
FunctionGetCustomerName()
'Dosomestuff
EndFunction
現在你想再寫一個類，它可以像呼叫本身的函數一樣呼叫基底類別的GetCustomerName函數。過去的方法是什麼呢？這在過去沒有辦法。然而，現在的新的方法只需在新的類別的上面插入如下簡單的一行語句：
InheritsBaseClass
FunctionGetCustomerID()
'Dosomestuff
EndFunction
編寫兩個或更多的名字相同但具有不同標識符的函數，這就是重載。在某種程度上，VisualBasic在函數呼叫時對內部類型的轉換以及屬性的設定中已經實現了重載。比較以下兩行有效的VisualBasic程式碼：
Text1.Text="7"
Text1.Text=7
在這兩個呼叫中，Text1中的text都將被設為字串「7」。這就是重載調用，因為VisualBasic知道如何處理輸入的不同的資料類型。它把它們當作變數處理，並自動進行轉換。當你呼叫一些參數型別有明確定義的函數時，VisualBasic也會作同樣的轉換。下面的兩個函數呼叫：
a=SetVal("This")
a=SetVal(7)
都可以正確呼叫以下函數：
FunctionSetVal(xAsString)
Form1.Text1.Text=x
EndFunction
既然VisualBasic已經可以傳送多種不同的變數類型，為什麼還需要重載功能呢？這是因為雖然目前單獨的一個函數已經可以處理多種資料類型，但它不能根據傳入的不同的資料類型產生不同的動作。相反的，比較以下兩個函數：
FunctionGetCustomerID(custnameasstring)AsInteger
'LookupcustomerIDbasedoncustomername
EndFunction
FunctionGetCustomerID(purchaslong)AsInteger
'LookupcustomerIDbasedonpurchaSEOrder
EndFunction
透過重載，你可以根據輸入的資料類型來實現函數。這對於下一個版本的VisualBasic是很重要的，因為它具有一個新的特性――缺省資料類型保護。一般來說變數的自動轉換是有利的，但可以想到有時也會為你帶來麻煩。例如在前面的SetVal的例子中，如果你要傳送的是字元7而不是字串“7”，那會發生什麼情況呢？下一個版本的VisualBasic將會自動捕捉這個錯誤。 （如果你的程式碼是基於VisualBasic以前的無型別辨識的功能，這個特性會被停用）
最後，多態性是已定義的類別的再定義過程。例如，你想寫一個BaseClass類的衍生類，但你想重新改寫GetCustomerName函數。在下一個版本的VisualBasic中，你可以用類似以下這種新方法來實現這種類別的定義：(注意：最終的語法取決於正式的版本)
InheritsBaseClass
FunctionGetOrders()
OverridesFunctionGetOrders()
•••
EndFunction
更多的文法特性
下一個版本的VisualBasic可能不隻隻有我以上提到的那些有關物件導向方面的改進。對於scalability和可重用性而言，還有一些線程生成、錯誤處理和許多長期以來一直被期待的新的改進。
目前，VisualBasic支援apartment-threaded模型。雖然這種模型為應用程式的開發提供了真正的高效率，但它還不夠理想。下一個版本的VisualBasic將在這方面有所改進。它採用freethreaded模型，這在編寫scalable的網路應用程式時將很有用處。 VisualBasic也會包含一些語法結構，你可以用來產生多執行緒。典型的執行緒發生操作如下所示：
sett=NewThread(NewThreadstart
(AddressOf(BaseClass.Function1))
從這個範例中，可以看到下一個版本的VisualBasic有AddressOf結構，用它來傳回函數的位址。你不再被迫跳過那些需要函數指標的API函數了！如果你需要返回調用，你可以利用它來做到這一點。
計劃中的另一項改進是結構化的出錯處理。不久前，VisualBasic也要求你在程式碼中插入大量的OnError聲明。多年來，我一直對插入如此多的GOTO語句感到不安。這些語句一再告誡我不要再使用它們！現在讓我們來面對這個問題――我們需要一種出錯處理機制。
下一個版本的VisualBasic採用集中處理出錯的方式。 VisualBasic將像那些「高尚的」語言一樣支援try...catch...finally結構。你可以在你的程式碼的頂端放置一個包含有出錯處理的子程式。這裡是實現出錯處理的一個例子：
SubSafeWrite()
Try
Open"Testfile"
•••
Write#1
Catch
Kill"Testfile"
Finally
Close#1
EndTry
EndSub
還有一些其他方面令人興奮的改進，現在的VisualBasic的使用者將會逐漸熟悉它們。在下一個版本的VisualBasic中，你可以在變數宣告的同時對變數進行初始化：
Dimaasinteger=10
你也可以在一個表達式中建立和初始化一個新的物件。你也可以透過類別來共享變數。最後，但不僅如此，繼承的概念擴展到了專案的使用者介面的基礎。關於VisualBasic的一個代表性的觀點是它很難在相同的基礎上建立多種不同的表單。 （在聯合開發的環境中，通常有這種要求）。在下一個版本的VisualBasic中，你可以透過模板類型來實現。
多年來，人們一直期待這些改進，這是為什麼呢？讓我們來看看。 VisualBasic的通訊（在這方面我已經從事了將近十二年）變得越來越複雜，遠遠超過1991年的第一版。 VisualBasic早期最初用於小型的便攜式的工具樣機的快速設計和開發。結果，VisualBasic獲得了「玩具語言」的名聲（在我看來，這是意料之外的）。現在它顯然不再是玩具了，再這麼說的人就是出於一種盲目的偏見了。現在各個領域都有大量的基於VisualBasic的軟體包。 VisualBasic正在發展著。去年，在中心研究所，我和一個軟體開發者進行了交談，他使用Web-Class編寫的程式每週接受上百萬次的點擊。
下一個版本的VisualBasic所發生的變化是令人驚訝的。如果你想獲得它們所帶來的那些好處，那就使用它們。如果你不想，你可以理直氣壯的使用你目前仍然使用的。然而，了解在像VisualBasic這種比C 和Java容易使用的多的語言中，也可以實現C 和Java所實現的功能，是有好處的。
未來的發展趨勢
這種預覽式的介紹你留下了什麼樣的印象呢？這個問題問得很好，但是你可以找到問題的答案。在過去的一年中，可以明顯的看到ASP開發的變化，這些開發程式常常由一些易讀的ASP腳本組成，在這些腳本的基礎上執行整個程式。由於ASP是對整個腳本程式碼進行解釋執行的，在對各組件進行組裝時，人們逐漸發現這種技術的固有的限制。我聽到越來越多的開發者說，他們要把他們的事件處理函數從腳本程式碼中完全脫離出來，放在更快捷的編譯方式的模型下實現，這些模型用C＋＋或VisualBasic編寫，透過COM接口進行組裝。
對於你所能想到的各種理由，VisualBasic都是能夠滿足的。使用VisualBasic來設計元件其實並不比使用VBScript或JScript®困難多少。你可以寫出執行起來更快的程式碼，而且很容易就能達到你的要求。當下一個版本的VisualBasic發布後，你可以使用VisualBasic來產生網路導向的對象，這種物件和ASP相容。總之，走組件組合的路線不管是現在還是將來都會被認為是最好的選擇。
正如我前面時候提到的那樣，使用VisualBasic(和WebClasses)編寫的面向Internet的應用程式已經有很廣泛的基礎。問題是，大部分的基於WebClasses的應用程式並沒有經過很好的設計。它們沒有很好地區分應用程式的不同的層次，把中間層的過程和基於DHTML的使用者介面混淆了。
下一個版本的VisualBasic將引入WebClasses，它是經過精心挑選後確定的網路開發的工具。因為它更有scalable、更強大、而且是真正的language-agnostic。它在VisualStudio的所有的工具中運作。如果你注意到多層開發的一些基本規則，你可以很容易地完成這個轉變。特別要注意，把中間層過程和顯示層過程分開。強烈建議在做這些工作時，參考Windows®DNA2000的體系結構。核心的事件處理功能必需在中間層完成，你可以使用各種你所喜歡的編譯語言編寫的用於實現這些功能的各個元件。然後，這些元件組裝在一個ASP腳本檔案中，這樣各元件就可以協同工作了。如果你把大部分的邏輯運算放在事件物件中而不是腳本中的話，那就是最理想的了。它不僅對將來向Webservices轉變是一個好的主意，它也是一種值得效仿的實踐。 ->