.NET断想

荣耀 2002秋

“遗留软件”和“遗留程序员”是阻碍.NET普及的最大阻力。另外一个阻力（听起来有点庸俗:)）是目前的Windows操作系统没有预装.NET框架。运行.NET应用，你需要另外安装.NET框架，这多少都有点麻烦。COM为何会在极短的时间内迅速取得成功，Windows内建了COM基础设施不能不说是原因之一。

微软当然比谁都清楚这一点，所以，“Windows .NET”系列操作系统，必然指日可待。

假如你对此观点不以为然，不妨看看CORBA在Windows平台上命运。当然了，这只是原因之一，而且，我说过，这个原因有点俗:)

不过在此也要纠正一个谬误。不在少数的程序员以为，在访问以ASP.NET技术创建的Web网页（.aspx）的客户端机器上，也必须安装.NET框架，这个概念是错误的。道理其实很简单 — 服务端总是返回生成的HTML。

无论微软如何宣称，无论.NET如何支持多种语言，都不会影响“C#是.NET最佳语言拍档”。

但在相当长的一段时间内，Visual Basic .NET或许反而会比C#占有更多的用户。原因并不复杂 — 现有的Visual Basic程序员为数众多 — 尽管今天的Visual Basic .NET早已不是从前的Visual Basic了。

Visual Basic程序员过渡到Visual Basic .NET，可能要比C++或Java程序员过渡到C#困难得多。

.NET框架由通用语言运行时（Common Language Runtime，CLR）和.NET框架类库构成。.NET在操作系统之上又加了一层抽象，.NET本身并不是操作系统。

为什么有那么多的人憎恶微软？这很让人费解。无论哪家公司，倘能取得微软这样的成就，都是了不起的。无论谁坐到了微软的位置上，估计都会这样。

憎恶微软的人，要么是微软的竞争对手，要么是非微软阵营的狭隘的开发人员，要么啥也不是，纯粹人云亦云，瞎起哄。

无论你多么憎恶微软，无论你怎样不喜欢.NET，假如你是一名“面向微软”的开发人员，学习掌握.NET只是早晚的事。

假如你是一名Windows开发人员，纵然你从来都不打算使用.NET技术进行实际软件开发工作，想对.NET完全免疫也是不可能的，你至少得知道它究竟是怎么一回事儿。

今后若干年内，.NET和Java将会形成分庭抗礼之势。两大阵营各有支持力量，只有在竞争中彼此学习互补，才能共同前进。任何一方都很难一口吃掉对方。

在软件开发世界，单极世界难免霸道，绝对不会长久；两极世界的平衡很难长时间维持，容易被打破；多极世界是丰富多彩了，但无疑将会成为开发人员的灾难，因为异质技术的整合，从来都是一场噩梦。

Java已经占据了大片地盘，在微软支持下，.NET将会最大限度地把pre.NET开发人员拉向自己的怀抱。在这个过程中，或许有人逃到Java阵营，但人数不会太多。道理很简单，假如你是一名微软技术开发人员，学习.NET所要花费的功夫，无论如何都不应该超过学习Java所要花费的功夫。

在从微软pre.NET技术过渡到.NET过程中，肯定会淘汰掉一些无法与时俱进的开发人员，这是正常现象。在技术进步的过程中，每一次创新，抱残守缺者总是会被毫不留情地抛弃。

自然选择，物竞天择。

有多少人会使用Managed C++？数目应该不会太乐观。相当一部分C++程序员往往会有某种没来由的优越感，对任何非C++的东西不屑一顾，大有万般皆下品，唯有C++高的感觉。在这些C++程序员的眼里，Managed C++已经算不上C++了，或者说，充其量，Managed Extensions for C++不过是微软对C++打的一个.NET补丁而已。

每一个严格符合.NET框架的语言的程序，最终都将被转换为MSIL代码（当然啦，有些语言只是提供了同CLR-based代码交互的能力，并不真的生成MSIL），但这并不意味着使用不同的.NET语言编写的功能相同的代码，将会转换成同样的MSIL代码。编译器的质量会有差别，生成的MSIL代码的质量也肯定会存在差异。

非微软的.NET语言据说已有两打之多，但它们很难成为主流。某些第三方.NET语言的现实意义，不过是提供了一种将现有代码移植到.NET之上的途径而已，另外一些仅仅具有学术研究方面的价值。

我不知道究竟会有多少人在.NET上使用Perl或者Python，尽管今天它们的拥趸的确不在少数。我只能肯定Delphi（Object Pascal）应该是个例外。

能否成为主流.NET语言，主要取决于：是否有足够多的“遗留软件”，是否有足够多的“遗留程序员”，是否有足够好的IDE，是否有实力足够雄厚的组织提供强力支持。

向来只有微软自己的技术才能和微软的技术最佳匹配，COM就是一个例子。COM无疑是pre.NET时代最成功的跨语言机制，但这种技术在跨微软自己的语言（确切地说，是开发环境），比如从Visual C++跨到Visual Basic以及相反时，表现还好，跨到了别的语言（开发环境），比如说Delphi，就会暴露出这样或那样的问题。

但愿类似的情况不会发生在.NET身上，但愿遵循CLS的语言果真可以完美无缝地互操作，就象微软自家生养的.NET语言一样:)

Web Services技术并非微软独创，也不是由.NET带来的，但仍然有相当一部分人误以为它是伴随微软.NET而来的技术。微软推广技术（概念）的功夫，由此可见一斑。

别误会，.NET Compact和.NET框架可以说是很不一样的东西。.NET Compact并不是从.NET框架中简单地砍掉一些东西之后的精简版，否则.NET Compact也不会比.NET框架晚交货那么长时间。

ASP.NET应用程序，就是.NET应用程序。普通ASP开发人员过渡到ASP.NET的痛苦，比起从Visual Basic过渡到Visual Basic .NET所要承受的痛苦（快乐？），不会少到哪里去。

ADO.NET是一种革命性的技术，尽管无可否认，它从Borland借鉴了许多数据存取技术，但ADO.NET对XML技术的支持，目前无疑处于领先地位。

我希望速度不要成为Web Services被广泛应用的阻力。在荣耀编写的一个测试应用中，整合来自不同厂商的Web Services的应用效果是令人惊讶的，不过，这个应用速度之慢，同样出人意料。

或许基于Web（WAN）的分布式计算，迫使我们不得不作出速度上的妥协，就象我们可以容忍（并且已经习惯）浏览器应用比传统Windows GUI应用来得慢一样。

.NET框架应用或许会比那些Windows DNA应用运行得慢，不过，我们真正应该关心的问题并非是这些应用到底能运行多快，而是它们是否足够快，快到可以满足用户业务处理的要求。

Java的成功已经提供了这些证据。尽管Java代码一般来说要比本地代码来得慢，但它还是足够快了，许多组织都非常成功地使用了这种技术。因此，对于.NET速度上的担心，完全是多余。按照微软自己的说法以及第三方提供的一些测试数据，.NET至少比目前版本的Java来的更有效率。

毕竟，硬件的品质也在不断提升。