消除.NET极度狂热下的四个误解

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



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

　　1. .NET 是基于 Win32 和 COM的

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

　　实际上，.NET在很大程度上完全是一个新的软件平台和组件结构。本质上，.NET把COM归入到一个“遗留的”环境中。这当然不是说COM应用程序在一夜之间就消失了；它们在未来的几年中很可能仍然存在。但是，正像Win32/COM在很短的时间内替代了基于字符的DOS应用程序一样，这个“新产品”将为从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和Win32 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的一个因素，这取决于你倾向于哪一侧市场阵营。业界人士普遍认为Microsoft技术不断扩大其使用范围，成为大企业的解决方案。这种观点的大部分是没有根据的，或者至少只有部分是正确的，它在很大程度上被竞争者们夸大了。但是，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、Perl、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#将压倒Visual 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语言之间进行权衡对比。(代码实验室)