google_ad_client = "pub-4944583547581781";
google_ad_width = 728;
google_ad_height = 90;
google_ad_format = "728x90_as";
google_ad_channel ="1429059098";
google_color_border = "FFFFFF";
google_color_bg = "FFFFFF";
google_color_link = "0000FF";
google_color_url = "000000";
google_color_text = "000000";
我撰写.NET技术通讯已经有大约三年时间，现在我决定停止这项工作。我认为有必要写一篇总结性的文章，阐述我对.NET当前状况及未来发展的看法。
2000年初，当.NET还在Beta版的时候，我就开始使用它了；在那个时候，它的名称是COM+2，主要的语言是Cool。其框架组件被简单地称为下一代Windows服务（NGWS），直到后来才由市场人士提出.NET这个名称，但是.NET这个名字却使互联网搜索引擎产生了混乱。你自问过.NET到底是什么意思吗？抑或它与.COM和.ORG有什么关系吗？当然，Cool的遭遇也好不到那儿去。后来他们有了一些灵感，决定把Cool更名为C#，但是C#好像最初也引起了搜索引擎和用户的混乱。搜索引擎不喜欢使用#字符，而用户则不知道这个字符该怎么读（C磅？还是东方的发音C号？）。我发表在技术新闻组上的第一篇文章是一个简单的Cool控制台应用程序、一个与其功能相当的Java程序，并提出一些问题指出了两者之间的差别。这引起了Visual Studio产品经理的强烈响应，他们没有真正地注意到我所指出的问题。
Visual Studio.NET与Visual Studio其它的版本不同，它的第一个beta版是开放的。任何人都可以下载并在beta新闻组中提交bug或问题。老实说，我不喜欢这种方式。我只是在公共新闻组中发表了一些可重复的bug，作为一个缄默的英国人，我不喜欢发表那些不可重复的bug，也不喜欢提出改善建议。我也没有看到关于这个大范围的、开放的beta版是否从发现的大量bug中受益的公开发表的结果；可是，我怀疑查找bug并不是其目的--更可能的情况是beta版的开放是为了使它尽可能的被大家接受。
我与其他人一样，开始的时候也被该框架组件的大小吓住了。它太大了！在过去的几年中我得出了一个结论：框架组件的大小是一种障碍。它里面的类太多了，尽管我也认为其中很多类是被良好地设计的，但是我仍然认为有一些是草率地完成的。其中有些类仅仅对Win32的简单包装，还有一些类看起来是从其它的框架组件中导入的。微软在发布.NET之前，已经拥有自己的Java框架组件类库（叫做WFC），还拥有一个传统的Visual Basic运行时部分的受控（managed）类库，如果我知道有多少WFC和VB类迁移到了.NET上就好了。但我能够识别出其中的一个，因为它在.NET和VB上运行的情况一样糟糕，这个类就是EventLog。这个类的行为与它在VB中的行为一样，在按照常规迁移到框架组件1.0版本之前，甚至于没有人关心它的设计。我在beta版中就抱怨过这个类，但是这个类的开发者只给出了一些毫无说服力的理由。最后，这个类在2.0中进行了“修补”，但是错误的方法还是没有被消除，因此我认为它根本就没有被“修补”过。
总体来说，我认为这个类库发布得太早了，同时它还太大了。该框架组件的可重新发布的部分（redistributable）有25MB，它比Java的可重新发布部分大很多倍。Visual Basic早期版本得出的经验是共享软件和免费软件市场造就某种语言的流行。尽管有些共享软件是使用.NET编写的，但是我经常听到人们抱怨那个巨大的可重新发布部分。我写过关于类库大小问题方面的文章，并且我始终认为如果微软提供删减过的、只带有微软核心类库和系统部件的框架组件版本是有好处的。
说起Visual Basic，我也想提出自己对它的看法，我不得不说传统的Visual Basic太老了。该语言天生就是单线程的，与COM交互（以及建立COM服务器）时会产生很严重的问题。实际上，在我写完一本关于MTS的书（1999年发表）的时候，就得出结论说MTS被设计为允许Visual Basic开发人员编写那些可以从多线程技术（threading）和安全技术（security）中受益的对象，而COM+则使其更进一步了。Visual Basic可以调用Win32函数，但是为了高效率使用这些函数，通常需要利用不太好的黑客技术。但是有了COM和COM安全技术之后，它向前迈进了很大的一步，不过还是不能用少量的几行代码来提供C++能够实现的功能。C++可以用很少的代码就能方便地实现而VB却无法像这样，实现任何功能都使VB非常窘迫。但是这种语言和在运行时（runtime）产生的大多数问题都是与生俱来的，因此，这些问题的解决方案非常激进。这导致了VB.NET的出现。
如果你搜索互联网，就可以找到很多关于VB.NET的发布引发狂热的资料。最好的是Karl E. Peterson的网站（http://www.mvps.org/vb/rants/vfred.htm）。但VB.NET简直就不是VB：Karl的网站显示在VB和VB.NET两种语言之间很多东西是不兼容的。另外，VB是单线程的，它不带异常处理，而且典型情况下是用于编写非OOP代码的。VB.NET带有一个"迁移"工具，但是我认识的使用过这个工具的大多数人都发现这个工具仅仅简单地标记出了大量的不兼容的代码。我早期的建议是VB开发者不要迁移自己的代码，替代的方法是，把代码转换为VB类，而这些类则可以通过COM交互操作（interop）而被.NET代码调用。采用这种方法，VB代码仍然能被保留在设计环境中。当然，微软继续说VB.NET就是VB的神话，鼓励大家使用这个迁移工具。
有些人认为VB.NET是令人叹服的。但是我真的没有察觉设计这种语言的动机。在VB.NET中其它语言所不拥有的特性很少（除了过滤器和接口方法的重命名），但是这对于产生一种新的语言来说理由是不充分的。有些人可能会说VB开发者使用VB.NET更加顺手，但是我前面说过，VB.NET不是VB，由于开发者必须学习OOP和.NET的原理，例如线程技术、异常处理和委托，开发者差不多学习了一门新的语言。C#是一种自然的可以用于.NET的语言，根本就不需要VB.NET。使用分号（;）和括号（{}）没有那么困难！它可以作为VB.NET的代替者，但是并非所有的语言都是这样的。我的看法是，通用语言规范（CLS）仅仅是简单地确保了在其它的语言中可以建立与VB.NET代码一起工作的代码，而不是使所有的语言协同工作。我知道有符号的（signed）整型数据是有用处的，但是无符号的（unsigned）整型数据也有用啊！我就不理解为什么VB.NET不把无符号整型作为语言的一部分。还有一些情况也是幼稚的，我们没有理由使用Option Strict Off（"延迟绑定"也与难以查找运行时bug是同义词），而且如果你没有显式地（explicitly）声明变量，那么很容易失去对这些变量的跟踪。VB.NET带来的少量优势不足以抵消它所拥有的这些严重的缺陷。
我曾经写过VB.NET的文章，也在VB.NET讨论会上发言过，因此我很了解这种语言。但是，它并没有使我感到舒适：我发现自己每次使用这种语言的时候，都少不了咒骂。它工作的情况就是与我预期的不一样，而且我也不是唯一的遇到这种情况的人。这是传统的VB迁移到VB.NET的时候我听到的最常见的抱怨，这也支持了Karl E. Peterson的断言--VB.NET不是VB。那么微软为什么创建VB.NET呢？其原因是在2000年的时候，VB开发人员的数量超过了微软的其它语言、超过C++用户数量至少10％（我在微软内部会议上看到过这个图表）。微软高调地宣布C#是 "来自C++家族"的另一种语言，并且市场人士认为他们不可能使所有这些VB程序员都使用类似C++的语言。替代方法是，他们认为如果微软建立一种类似VB的语言，这些VB程序员中相当比例的人更有可能迁移到.NET上。换句话说，VB.NET的出现是市场的原因而不是技术的原因。
有必要指出，.NET大体上与传统的VB有很多相似之处。.NET与VB一样可以使用接口（interface），接口是非常精致的（elegant），但是.NET却推荐使用基于类的解决方案，这标志着接口的消亡。
我们再来看一看.NET remoting（远程技术）：微软提供.NET remoting用于允许创建于自己的环境中并且运行着的对象被另一个环境调用。这意味着该对象的状态是本地的（local），而它的行为则是远程的（remoted）。因此，remoting是一个基于接口的工具。你可以利用接口来使用.NET remoting，但是如果你阅读文档或者访问Web上的"how－to（操作指南）"，你就根本意识不到这一点。作为代替的是，微软推荐人们使用基于类的方法，这通常会导致一些奇怪的现象出现--人们向客户端部署服务器部件，这样客户端才拥有可用的服务对象的元数据（metadata），或者导致泡沫部件，它使哪些基于类的remoting问题四处散播。
.NET非常象VB的另一个地方是微软对它的框架组件的态度。微软把.NET作为扩展自己的产品的一个有用的类库，但是到目前为止，微软却没有显示出对该框架组件的更大的信心。目前只有很少的.NET产品是整个地使用.NET编写的；其中一个是微软的CRM。但是，它们却不是微软主要的收入来源。作为代替，.NET被更新到已有的产品中，并用于扩展这些产品。即使Visual Studio .NET也不是.NET产品。devenv.exe是一个用C++（大概是MFC）编写的非受控（unmanaged）过程。VS.NET寄宿了.NET运行时，这样它就可以使用类似属性表格的.NET对象，并且它可以被写成.NET部件的代码扩展。我认为这是微软未来使用的模型。他们不希望承担为.NET重新编写代码的开销，而且没有谁强迫他们在.NET中提供全新的代码；.NET将会被寄宿，并且在需要的时候，允许通过用户提供的代码来进行扩展。
微软当前的操作系统XP和Windows 2003并不依赖于.NET；而且XP中.NET是一个可选组件。下一个版Windows（叫做Longhorn）在2003 PDC上作为技术预发布过，看起来.NET贯穿着这个操作系统。但是到发布的时候会发生很多变化的。在过去的一年中，微软发表了很多声明，表现出它更关心原定的发布日期2006年，而不是对新技术的热情。第一个障碍是WinFS，很明显这种技术会使Longhorn更慢，特别是WinFS使Outlook Express根本就无法使用。但是微软的做法并不是使这种技术能够正常工作，而是选择删除了它。在你阅读这几行的时候，我在怀疑这种技术是否能够返回应用。其次，微软宣称Longhorn中的另外两种.NET技术--Indigo和Avalon，将可以在其它版本的Windows中使用。Indigo是一种通讯技术，因此其它版本的Windows使用它是有意义的。但是，我认为使Avalon可用于其它版本的Windows表明微软对Longhorn的销售不太自信。
我的看法是Avalon--更具体地说是XAML，将标志着ASP的消亡。其原因在于Avalon是一种客户端技术，而浏览器则是该分布模型的一个重要部分。XAML的功能如此丰富，以至于包含浏览器的XAML应用程序与基于过程的Avalon应用程序看起来没有差别，而且与Web服务或者Indigo（作为访问远程代码的机制）耦合之后，XAML应用程序会使ASP.NET应用程序看起来毫无价值和陈旧不堪。微软为什么想毁掉ASP呢？安装ASP.NET的时候，微软会卖出一套Windows 2003，同时还可能卖出几套Visual Studio.NET。客户端可以不是Windows，因此微软不会有其它的销售收入（无论是产品或许可）。这是一块很大的收入来源，更糟的是，ASP.NET实际上使编写应用程序更加容易了，而且它还可以被IE以外的浏览器使用。但是，使用类似XAML技术的时候，微软对客户端有控制权。因此，除了服务器和开发工具之外，客户端也必须拥有Avalon技术。假如客户被说服了，升级到Longhorn，那么它就可能是微软巨大的收入来源。但是微软宣称Avalon将可以用于其它版本的Windows，向我表明他们对Longhorn的预计也不是那么自信，并且如果开发者不能确定客户端是否会运行Avalon应用程序，那么他们就不会为Avalon编写应用程序。
因此，从去年的声明中可以看出，微软认为Longhorn并不是在PDC 2003上取得我们信任的伟大的.NET变革。这表明微软正在逐步失去对.NET的信心。当我看到Longhorn的beta版的时候（应该是今年年末），我会仔细地检查它到底有多少是用.NET实现的。我怀疑只有很少的一部分会用.NET来实现。我们可以找到一些线索：如果Longhorn没有实现命令解释程序（shell），或者不允许你用.NET扩展命令解释程序，那么很明显微软失去了信心。如果Longhorn没有实现.NET中的任何服务，那么就表明.NET并不是在LOCALSYSTEM帐号权限下运行的正确的技术。
你读到这儿时候，得到的印象可能是我对.NET的看法是愤世嫉俗的。它的框架组件有很多承诺，但是我认为微软的野心太大，以太快的速度发布了太多的部件。微软为了提供向后的兼容性，不能简单地重新设计整个类库并抛弃旧的类库。因此我们得坚持使用现在所拥有的类库。微软允许市场优先于技术：他们建立并宣传VB.NET仅仅是为了使Windows开发人员使用.NET，而不是因为需要这种语言。它的框架组件变成了Visual Basic--它是供用户开发应用程序的，而不是供微软建立操作系统或建立他们所依赖的带来收入的产品的。
本文地址：http://com.8s8s.com/it/it41476.htm