消除关于.NET的四个误解

Visual Studio .NET (VS.NET) 终于发布了，这个新平台很快在开发人员中流行开来。然而，同任何新的技术一样，人们对它也有很多担心、不确定和迟疑--这种想法甚至比其它产品的更多。在同.NET的预期采用者们进行谈论时，我发现人们对它的几个普遍的误解似乎是造成这种担心和恐慌的原因。 
本月我将重点解决人们对.NET的四个最大的、最普遍的误解。它们不仅会给人们带来相当大程度的、毫无根据的担心，在某些情况下，也会让人们对.NET产生极度的狂热--这两种情况都会对成功采用.NET策略造成危害。 
1. .NET 是基于 Win32 和 COM的  
 
 
 
的确，.NET构架是依赖于底层的Win32 APIs而连接到OS的。然而，典型的.NET开发人员--不同于如今的COM开发人员（尤其是C++程序员）--将很少直接暴露在底层的Win32层中。作为替代，.NET构架包含它自己的类库，这个类库既完全代替了底层的部分Win32层，又作为一个封装机制将开发人员同其它部分的细节隔离开。正像Visual Basic以前的版本将开发人员同许多Win32的低级的"plumbing"细节隔离开一样，.NET取得了更大的进展，它提供了一个完整的多语言软件平台，该平台在很大程度上完全从底层的OS隔离出来。所以，从传统意义上讲，典型的.NET开发人员绝对不是Win32开发人员。  
 
 
 
 
一个"+"号带来多大的不同。虽然.NET在很大程度上是COM的替代，但它不是COM+的替代--至少现在还不是。这是一个很容易犯的错误，因为COM和COM+这两个名字很像。虽然COM是一个组件模型，但COM+是一组以中间件为中心的应用程序服务。实际上，虽然它们常一起使用，但COM+和COM在很大程度上是相互独立的。  
COM+服务，如异步的消息（MSMQ）和事务处理（MTS），构成了Microsoft的中间件软件堆栈的支持功能。这些服务共同构成Microsoft DNA 结构的"应用程序服务器"层--尽管Microsoft并没有明确地用那个术语。 
这就在.NET开发人员中形成了支持派和反对派两个阵营。虽然诸如ASP.NET之类的功能增强了.NET的可扩展性，但是这种可扩展性在很大程度上仍然取决于COM+ 自身的可扩展性和稳定性。不管怎样，.NET在可扩展性和稳定性方面并没有带来很大的改变。你可以把这一点作为有利于.NET的一个因素（它的底层框架是经受了考验的），或者你也可以把它作为不利于.NET的一个因素，这取决于你倾向于哪一侧市场阵营。业界人士普遍认为Microsoft技术不断扩大其使用范围，成为大企业的解决方案。这种观点的大部分是没有根据的，或者至少只有部分是正确的，它在很大程度上被竞争者们夸大了。但是，COM+ 仍然担起了这副重担，而.NET既不排斥这种误解，也不对它进行补充。  
但是，总体上说，在"首先不伤害"现有的COM+底层框架这个法令下，大多数.NET的功能目前主要集中在生产力、方便开发、一致性等等方面。因此，Microsoft的实质性的R&D力量就主要集中于让开发人员确信.NET没有给现有的COM+结构增加相当大的费用。但是.NET并没有解决当前COM+的许多不足。例如，ASP.NET仍然是IIS的扩展。这就是说，所有IIS的不足（安全性、稳定性等等）在ASP.NET应用程序中仍然存在，就如同它们在ASP系统中一样。应用程序层已经得到了极大的改进，但是底层的IIS固疾仍然存在。  
 所有.NET语言都是平等创建的 
实际上，Java支持其它编程语言（如Jpython），但它们都没有引起人们广泛的关注。例如，虽然Python如今是一个受的Internet脚本语言，但是Jpython--基于Java的版本--只拥有很小一部分Python用户。如今，99%的Java应用程序都是用Java语言编写的。  
不幸的是， 理想的语言"公平竞争环境"只能是种理想。事实离这种承诺相差很远。一些语言比另外一些语言更适合.NET，在.NET中尽量运用更多这样的语言就像努力把一个正方形的木桩放到一个圆的洞中一样。这并不是说这种概念没有价值；无疑它是有价值的。但是开发人员在实现这种理想前，他们必须对这种承诺采取保留态度。例如，许多编程语言必须被改进，以使它们符合.NET的普通数据类型和运行环境。在一些语言中已经做了重大的折衷，如Perl、Smalltalk和其它语言。例如，ActiveState的Visual Perl和Visual Python不生成.NET本地代码；作为替代，它们将封装类用于传统的运行环境。正如Java的宣传语"一次编写，随处运行"一样，它从来没有把这种市场宣传变成事实，随着时间的推移， 作为"语言公平竞争环境"的.NET将同样证明，这种说法更多是一种市场宣传，而不是事实。