垃圾回收机制同时也意味着,当对象的最后一个引用被释放时,对象并不一定立即被拆除。
采用垃圾回收机制的一个后果是:我们不能再希望类的Terminate 事件总是适时触发。事实上,如果线程被阻塞的话,Terminate 事件可能完全不会触发。
这就是所谓的“非确定的结束”(non-deterministic finalization),而COM 提供的则是“确定的结束”。由于缺乏“确定的结束”,再加上因为垃圾回收器重新组织和整理内存导致不能运用指针,新闻组中出现了对该问题激烈的争论:有些人憎恨这些新的限制,因为他们依赖于“确定的结束”;有些人觉得无关紧要,因为他们并不依赖于Terminate 事件。
从引用计数转变到垃圾回收仅仅是Visual Studio.NET 底层体系不再是COM这一变化的诸多必然结果之一。虽然VB.NET之内仍旧可以使用COM 对象,但这些对象必须通过封装(Wrapper )才能访问。任何时候,封装都意味着性能的降低,甚至还有可能导致对象行为的异常。如果要迁移一个大量使用COM 对象的工程,你必须认真地进行计划和测试,应用程序的某些部分可能还需要重新构造。
七、面向Web 的支持除了Windows Forms 新引擎之外,。NET 还包含了一个专门为构造Web 窗体设计的窗体引擎,称为Web Forms.这个引擎的目标在于让用户能够象创建传统Windows 桌面应用的窗体一样方便地创建Web 窗体。Web Forms是一种ASP.NET 技术,通过它我们可以使用熟悉的RAD (快速程序开发)工具构造出带有执行代码的窗体。不过,窗体中的ASP.NET 代码以编译方式在服务器端运行,经过处理后把结果HTML发送给支持HTML 3.2的浏览器。
客户端事件数据由底层框架截获并发送到服务器。这意味着应用界面不再受浏览器类型的约束,意味着有大量UI工具可供使用,意味着用户可以充分发挥现有的窗体制作技巧。如果应用没有必要做到浏览器中立,那么它就可以利用IE浏览器的各种特色。有了Web Forms ,我们将能够更轻松地为那些具有Web 功能的应用构造出更好、更丰富的用户界面。
VB.NET中另外一个面向Web 的重要特色是Web 服务。在Microsoft 的宣传中,Web 服务被推崇为之所以要采用。NET 技术的重要理由之一。事实上,从根本上来说Web 服务是一种类似COM 的、通过Web 服务器和标准协议发布的对象。当然,Web 服务并不是严格意义上的COM 对象,但两者作用方式类似。Microsoft 期待着各类公司都以Web 服务方式提供服务,期待着未来创建应用时只需简单地“粘合”各种服务,就象今天借助Office和支持VBA 的应用通过VBA 构造新应用一样简单快捷。
从Microsoft PDC (Professional Developers Conference,专业开发者大会)的一个演示中,我们可以看出Microsoft 希望开发者如何粘合各种Web 服务。
在这个演示中,一个假想的医生以Web 服务形式发布其时间表,示范如何通过Web 用智能电话和医生订立约会。Visual Basic.NET还允许查询服务器,提取服务器支持的所有服务的元数据。Web 服务描绘了Microsoft 野心勃勃的战略,然而,唯有时间才能告诉我们Microsoft 是否在大范围推广Web 服务上取得了成功。但不管如何,这个想法本身看来有着美好的前途。
为了减少与封装和分发应用有关的问题,如令人畏惧的DLL Hell问题(在共享DLL 的应用之间,由于一个应用的升级而导致另一个应用无法正常运行的情况),Microsoft 作出了种种努力,它同样也带来了美好的希望。所有。NET 应用都封装为程序集(Assembly)。程序集包含了描述各种运行需求的元数据。这种元数据称为manifest,其中包括:程序集的标识信息(名称,版本等),列出了所有文件依赖关系以及文件位置和文件版本的文件清单,外部依赖信息(带有描述程序集必须用到、但开发者没有自己创建的DLL 以及其他资源的数据)。程序集是通过manifest自我描述的,因此。NET 应用的运行并不需要修改注册表。换句话说,。NET 应用不再要求注册组件。在最理想的情况下,客户机器上已经有了。
NET 运行环境,部署一个复杂的应用简单到只需复制一个文件夹到目标机器。使用程序集的另外一个优点是:不同的应用可以拥有同一DLL 的不同版本,所有这些应用都互不干涉地在同一台机器上运行。如果它能够按照预期那样获得成功,DLL Hell和可怕的版本问题都将成为历史。
Visual Basic.NET代表着VB的一次重大飞跃。尽管如此,把VB.NET看成是一种有着熟悉语法的新语言而不是对旧语言的简单升级或许是对待VB.NET较为正确的心态。

