消除关于.NET的四个误解

http://www.fawcette.com/China/DotnetMagazine/2002_07/article.asp?page=1&xml=C
learing

同任何新的技术一样，人们对.NET也有一些误解。让我们来看看四个最普遍的误解的真
实情况吧。
by Mark Driver
涉及技术： .NET Framework, Visual Basic .NET, C#
Visual Studio .NET (VS.NET) 终于发布了，这个新平台很快在开发人员中流行开来。
然而，同任何新的技术一样，人们对它也有很多担心、不确定和迟疑——这种想法甚至
比其它产品的更多。在同.NET的预期采用者们进行谈论时，我发现人们对它的几个普遍
的误解似乎是造成这种担心和恐慌的原因。

本月我将重点解决人们对.NET的四个最大的、最普遍的误解。它们不仅会给人们带来相
当大程度的、毫无根据的担心，在某些情况下，也会让人们对.NET产生极度的狂热——
这两种情况都会对成功采用.NET策略造成危害。

1. .NET 是基于 Win32 和 COM的
Microsoft的组件对象模型（COM）是Windows应用程序组件结构的核心和灵魂。过去，CO
M是Microsoft操作系统中编写的应用程序、组件、工具和构架的主要的互用层。如今，.
NET和COM的关系使许多开发人员把他们混淆在了一起，他们错误地认为.NET是现有的COM
结构的扩展和演变。换句话说，许多开发人员认为.NET是基于COM的。

实际上，.NET在很大程度上完全是一个新的软件平台和组件结构。本质上，.NET把COM归
入到一个“遗留的”环境中。这当然不是说COM应用程序在一夜之间就消失了；它们在未
来的几年中很可能仍然存在。但是，正像Win32/COM在很短的时间内替代了基于字符的DO
S应用程序一样，这个“新产品”将为从COM到.NET的过渡提供一个起点。

在向.NET的过渡过程中，你可能会看到投入市场的新的基于COM的应用程序越来越少。渐
渐地，随着时间的推移，.NET将替代基于COM的应用程序，先形成一个混合的模式，然后
到2005年，对于大多数基于Microsoft的解决方案，将会形成几乎100%的纯粹的.NET应用
程序。

开发人员对.NET和合称为Win32的传统的“本地”Windows编程APIs之间的关系也感到困
惑。Win32描述了一系列具有各种兼容性的操作系统（OS），从现在不支持的Windows 95
到Windows XP。虽然将.NET描述成是基于Win32的会稍微精确一些，但这种概念也并不完
全正确。
的确，.NET构架是依赖于底层的Win32 APIs而连接到OS的。然而，典型的.NET开发人员
——不同于如今的COM开发人员（尤其是C++程序员）——将很少直接暴露在底层的Win32
层中。作为替代，.NET构架包含它自己的类库，这个类库既完全代替了底层的部分Win32
层，又作为一个封装机制将开发人员同其它部分的细节隔离开。正像Visual Basic以前
的版本将开发人员同许多Win32的低级的“plumbing”细节隔离开一样，.NET取得了更大
的进展，它提供了一个完整的多语言软件平台，该平台在很大程度上完全从底层的OS隔
离出来。所以，从传统意义上讲，典型的.NET开发人员绝对不是Win32开发人员。

对许多开发人员来说，他们对COM和Win32的低级的细节问题感到很苦恼，所以.NET很受
他们的欢迎。对另外一些人来说，.NET的确让他们感到恐慌。正因为.NET是“新奇”的
，才形成了这种“玻璃杯半空半满”的情况，我在二月份的专栏中对此做过探讨（见资
源）。一方面，.NET引进了另人兴奋的和有价值的新功能；另一方面，它是以一个新的
、未经考验的应用程序构架为代价的。

因为.NET构架包括一个到老的COM世界的有力的过渡，所以相继产生了另外的误解。实际
上，开发人员可以将软件服务（如程序、组件、模块等等）呈现成COM组件，让.NET组件
来使用。同样，开发人员可以将.NET组件呈现为标准的COM组件。

一个.NET开发人员可以完全不用COM代码来构建整个应用程序系统。他或她也可以构建“
混合的.NET”解决方案，将遗留的平台同新的平台结合起来。在Gartner公司，我们认为
这种混合模式将在采用.NET的最初几年内占统治地位，因为大多数开发人员在匆忙重写
他们现有的COM应用程序时，发现TCO或ROI优势并不多。因此，一种“如果没有被破坏，
就不要修理”的策略使人们将现有的COM服务同不断形成的.NET技术结合起来使用，这种
趋势将至少持续到2004年。

.NET采用者的经验：最不会带来伤害的采用策略就是避免陷入企图将你现有的基于COM的
应用程序“扩展”得太多这种陷阱。你也应该避免仅仅因为.NET很新就立即完全重写你
现有的系统。对大多数企业来说，将.NET直接但渐进地灌输到一个软件开发策略中是最
好的方法。采用一个进度，在未来的三到四年内慢慢地、安全地转移你对低级的COM和Wi
n32 APIs的依赖。
2. .NET 是COM+的替代
一个“+”号带来多大的不同。虽然.NET在很大程度上是COM的替代，但它不是COM+的替
代——至少现在还不是。这是一个很容易犯的错误，因为COM和COM+这两个名字很像。虽
然COM是一个组件模型，但COM+是一组以中间件为中心的应用程序服务。实际上，虽然它
们常一起使用，但COM+和COM在很大程度上是相互独立的。

COM+服务，如异步的消息（MSMQ）和事务处理（MTS），构成了Microsoft的中间件软件
堆栈的支持功能。这些服务共同构成Microsoft DNA 结构的“应用程序服务器”层——
尽管Microsoft并没有明确地用那个术语。

虽然.NET构架、组件模型和分布机制（装配）在大多数情况下代替了COM中同等的概念，
但是同在它之前的COM/Win32应用程序一样，. NET应用程序仍然运用底层的COM+服务。
换句话说，.NET构架没有与诸如MTS或MSMQ之类的服务等同的本地概念。确切的情况是，
.NET提供了一组封装类，作为现有的COM+服务的适配器。

这就在.NET开发人员中形成了支持派和反对派两个阵营。虽然诸如ASP.NET之类的功能增
强了.NET的可扩展性，但是这种可扩展性在很大程度上仍然取决于COM+ 自身的可扩展性
和稳定性。不管怎样，.NET在可扩展性和稳定性方面并没有带来很大的改变。你可以把
这一点作为有利于.NET的一个因素（它的底层框架是经受了考验的），或者你也可以把
它作为不利于.NET的一个因素，这取决于你倾向于哪一侧市场阵营。业界人士普遍认为M
icrosoft技术不断扩大其使用范围，成为大企业的解决方案。这种观点的大部分是没有
根据的，或者至少只有部分是正确的，它在很大程度上被竞争者们夸大了。但是，COM+
仍然担起了这副重担，而.NET既不排斥这种误解，也不对它进行补充。

然而，一些主要领域中的早期的成果在表面上是有利于.NET的。例如，我从.NET beta版
测试人员和早期采用者那儿得到的关于ASP.NET的稳定性和速度方面的报告就是很好的。
由于Internet Information Services（IIS）和Active Server Pages（ASP）众所周知
的不足，ASP.NET的引进就很快流行起来（见资源）。许多开发人员已经发现了直接的、
强大的理由（如性能和稳定性）来尽快采用.NET构架的ASP.NET部分，而且还汇报了其相
对于ASP的主要的优势。
但是，总体上说，在“首先不伤害”现有的COM+底层框架这个法令下，大多数.NET的功
能目前主要集中在生产力、方便开发、一致性等等方面。因此，Microsoft的实质性的R&
D力量就主要集中于让开发人员确信.NET没有给现有的COM+结构增加相当大的费用。但是
.NET并没有解决当前COM+的许多不足。例如，ASP.NET仍然是IIS的扩展。这就是说，所
有IIS的不足（安全性、稳定性等等）在ASP.NET应用程序中仍然存在，就如同它们在ASP
系统中一样。应用程序层已经得到了极大的改进，但是底层的IIS固疾仍然存在。

你可以期望， Microsoft在2002年努力推动向.NET移植后，它下一阶段的努力将集中在
增强可扩展性和性能方面。

3. 所有.NET语言都是平等创建的
.NET构架引进了很多新的、扩展的技术，它们主要针对各种下一代软件服务。在这些新
功能中，支持多种语言成为与其它竞争平台——即Java——明显不同的一个功能。与让
开发人员用一种开发语言的Java不同，.NET强调开发人员可以运用他们现有的技术，并
把这些技术延伸到.NET中。

实际上，Java支持其它编程语言（如Jpython），但它们都没有引起人们广泛的关注。例
如，虽然Python如今是一个受欢迎的Internet脚本语言，但是Jpython——基于Java的版
本——只拥有很小一部分Python用户。如今，99%的Java应用程序都是用Java语言编写的
。

另一方面，.NET强调了其运用现有的技术集合和编程语言的能力，如Visual Basic、Per
l、C++、甚至Java。实际上，许多其它的.NET编译器已经开始出现了，从不知名的编译
器（Scheme.NET）到确实无名的编译器（SML.NET）。

不幸的是， 理想的语言“公平竞争环境”只能是种理想。事实离这种承诺相差很远。一
些语言比另外一些语言更适合.NET，在.NET中尽量运用更多这样的语言就像努力把一个
正方形的木桩放到一个圆的洞中一样。这并不是说这种概念没有价值；无疑它是有价值
的。但是开发人员在实现这种理想前，他们必须对这种承诺采取保留态度。例如，许多
编程语言必须被改进，以使它们符合.NET的普通数据类型和运行环境。在一些语言中已
经做了重大的折衷，如Perl、Smalltalk和其它语言。例如，ActiveState的Visual Perl
和Visual Python不生成.NET本地代码；作为替代，它们将封装类用于传统的运行环境。
正如Java的宣传语“一次编写，随处运行”一样，它从来没有把这种市场宣传变成事实
，随着时间的推移， 作为“语言公平竞争环境”的.NET将同样证明，这种说法更多是一
种市场宣传，而不是事实。

事实就是只有少量的语言可以支配.NET的开发。在Gartner，我们认为直到2005年，VB和
C# 将支配至少80%的基于.NET的开发。所以，虽然的确你可以将Pascal或COBOL编译器用
于.NET，大多数开发人员对此并不关心。
4. C# 将毁掉 Visual Basic
对.NET编程语言的争论导致了关于.NET的最后一个误解。许多开发人员认为C#将压倒Vis
ual Basic（也许甚至毁灭它）成为.NET的首选语言。这种观点的形成有许多因素。正如
我在以前的文章中谈论的那样，VB.NET不是你的父辈用过的Visual Basic（见资源）。
它对Visual Basic做了很多改进，使它充分与.NET平台结合在一起。一些人认为从VB6移
植到VB.NET大概就相当于移植到C#。不要相信他们这种说法。

的确，说得婉转些，VB.NET和C#都需要开发人员了解底层的.NET构架的结构及其重要的
学习曲线。 这个学习曲线对于所有的.NET语言都是类似的。然而，这并不是从VB转到C#
的一个强大的理由。实际上，VB程序员转到C#来利用.NET构架中的功能并没有什么强大
的技术原因。

作为 C家族的编程语言，C#有一定的优势，所以，对现在的C、C++和Java开发人员来说
，C#更吸引人。但是VB.NET，虽然在很多方面都不同于VB6，它仍然保留VB 4GL的语法，
并且是拥有全世界50%开发人员市场的一个编程工具“中心”。在Gartner，我们预计，
从VB6移植到VB.NET将平均花费VB程序员约四个月的时间（取决于开发人员的情况），而
从VB6移植到C#将花费约六个月的时间。这个时间段包括正式的培训，以及“实战”训练
，以便熟练使用新的语言和构架。在这两种情况下，大部分时间都用来学习新的构架。
在大多数情况下，从VB移植到C#只是增加了更多的变量，而没有带来重大的回报。

这并不是说C#不成功。的确，Gartner公司预计，当Visual C++开发人员采用.NET时，大
部分人会积极地移植到C#。而且，第一次移植到.NET的许多开发人员将选择这种“本地
”.NET编程语言作为他们主要的工具。

.NET 很新：在它今后的几个月、几年内的发展过程中，你应该预料到会碰到一些误解和
错误的设想。开发人员必须将他们的期望建立在根本的事实基础上，在运用.NET的“新
功能”和运用“没有被破坏的”现有的COM构架和VB语言之间进行权衡对比。

关于作者:
Mark Driver是IT行业研究公司Gartner的研究室主管，他主要进行用于分布式Internet
和移动电子商务解决方案的应用程序开发策略、工具和技术的研究。他的e-mail是：dot
[e-mail]。