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转变是一个好的主意，它也是一种值得效仿的实践。->