正在阅读：消除.NET极度狂热下的四个误解消除.NET极度狂热下的四个误解

2004-02-14 09:34 出处：PConline 作者：AthlonXP 责任编辑：huangpeidan

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的依赖。