最近我通读了Richard Grimes在Dr. Dobbs Journal上发表的文章"Grimes的告别.NET书"。我想对该文章中Richard的观点作一些回应。Richard明确地宣称该文章是"自己的观点"，也就是说，他的文章应该被看作是他自己对于.NET当前的情况的看法，而不是讨论我们走了多远、要到哪里去。他提出了三个论点--.NET框架组件太大了以至于妨碍了它的应用，.NET框架组件的设计问题，文章还有大约一半的内容在抨击Visual Basic，最后的结论是微软对.NET框架组件"失去了信心"。在下面的内容中，斜体字是引用他的观点，后面是我的回应。
对于.NET框架组件的大小妨碍了它的应用问题
·RG：该框架组件的可重新发布部分(redistributable)有25MB，比Java的可重新发布部分大很多倍。Visual Basic早期版本得出的经验是共享软件和免费软件市场造就某种语言的流行。尽管有些共享软件是使用.NET编写的，但是我经常听到人们抱怨那个巨大的可重新发布部分。
我的回应：也许是我过于挑剔了，但是它的大小的确是23,698K或23.7MB。尽管Java的运行时相对较小，但是还是有15MB。通观全文，Richard谈到.NET应用程序的时候，他谈到的实际上是客户端或公共客户端(即不在防火墙内)。例如，把.NET框架组件安装在服务器上，或者安装在你可以控制的内部网环境中根本就不会有问题。即使在公共客户端计算机上，也有大量的商业共享软件--从游戏到RSS阅读器--都需要.NET框架组件。我曾经询问过很多共享软件开放人员，他们的确没有使用Java，多数人使用C/C++、Visual Basic或Delphi。在谈".NET的状况"的时候，开发部副主管Soma的关于.NET的能量的文章做了更好的总结。
Soma：到目前为止，我看到人们从Windows更新和微软下载中心下载了7000万次.NET框架组件。简单的计算一下，这个数据可以转换为每个月下载550万次。另一个有趣的数据是，在2004年，我们预计约有5400万台新PC中会安装/预装.NET框架组件。我们还拥有大约250万受控代码开发者。
关于.NET框架组件的设计的问题
·RG：我发表在技术预览新闻组上的第一篇文章是一个简单的Cool控制台应用程序、一个与其功能相当的Java程序，并用一些巧妙问题指出了两者之间的差别。
·RG：其中有些类仅仅是Win32的包装，还有一些类看起来是从其它的框架组件中导入的。微软在发布.NET之前，它已经拥有自己的Java框架组件类库(叫做WFC)，还拥有一个作为传统的Visual Basic运行时部分的受控(managed)类库。如果我能知道有多少WFC和VB的类迁移到了.NET就好了。
我的回应：这两个观点是矛盾的。在第一个观点中他暗示.NET框架组件是Java的复制品，但是在后面一个观点中，他声明.NET框架组件简单地迁移自Win32类、Windows基类(WFC)和VB运行时类。他的观点到底是哪一个呢？如果他的观点是可以编写一个简单的应用程序，该程序在C#、Java或C++看起来一样，那么我认为这根本就不能证明什么。看看下面的一个for循环：
for (int i = 0; i < x; i++) {...}
猜猜它是用哪种语言编写的？如果你的回答是C、C++、C#和Java，那么就答对了。我看不出他到底想证明什么。如果他试图建立一个比"Hello World"更加强大的应用程序，那么就应该在框架组件或类库的具体特性(ATL不是，MFC也不是EJB等等)下运行。
关于基于接口的编程和Remoting技术的问题
·RG：接口是非常精致的(elegant)，但是.NET却推荐使用基于类的解决方案，这标志着接口的消亡。我们来看一看.NET remoting(远程技术)：微软提供.NET remoting用于允许在创建自己的环境中运行的对象被另一个环境访问。这意味着该对象的状态是本地的(local)，而它的行为则是远程的(remoted)。因此，remoting是一个基于接口的工具。你可以利用接口来使用.NET remoting，但是如果你阅读文档或者访问Web上的"how-to(操作指南)"，你就根本意识不到这一点。
第一点--接口消亡了
我的回应：.NET框架组件中到处都用到了接口，接口在类似VB或C#的特定的单层继承语言中特别有价值。即使最简单的String类也有IComparable、ICloneable、IConvertible和IEnumerable接口。再向前看，.NET框架组件2.0的关键的新特性--泛型(generics)--也用接口来约束数据类型。
第二点--缺少在.NET Remoting中使用接口的文档
我的回应：我决不说我们的文档是没有瑕疵的，我可以提供一个链接关于Remoting的.NET框架组件SDK示例。请注意下载的第五个示例就是在remoting中使用接口。
·RG：.NET可以使用接口(interface)，但是推荐的方法是使用类。
·RG：微软的替代作法是推荐人们使用基于类的方法，这通常会导致一些奇怪的现象出现--人们向客户端部署服务器部件，这样客户端才拥有可用的服务对象的元数据(metadata)，或者导致泡沫部件，它使哪些基于类的remoting问题四处散播。
我的回应：我们本身没有"推荐"任何机制。尽管我们可能提供了指导，但是开发者可以选择自己认为合适的方法开发应用程序。我们的模式和实践小组的确提供了这些方面的指导和最佳经验，并在如何设计远程接口中包含了向导。我看不出来我们偏好于基于类的方式，实际上，使用面向消息和服务的比使用面向对象的要增长得快一些。我承认需要把服务器部件部署到客户端上，但是不好的设计就是不好的设计，别无其它。把服务器部件部署到客户端上，使服务器对象的元数据可用，可以让人们容易地使用接口或大纲(schema)。这就是说，存在一些希望每个客户端拥有服务器代码的情形，例如对等(peer-to-peer)聊天就要求客户端同时承担客户端和服务器的角色。
关于微软在产品中使用.NET框架组件的问题
·RG：微软把.NET作为扩展自己的产品的一个有用的类库，但是到目前为止，微软却没有显示出对框架组件的更大的信心。目前只有很少的.NET产品是整个使用.NET编写的；其中一个是微软的CRM……他们不希望承担为.NET重新编写代码的开销，而且没有谁强迫他们在.NET中提供全新的代码；.NET将会被寄宿，并且在需要的时候，允许通过用户提供的代码来进行扩展。
我的回应：我们需要把Richard的话进行分解。他说微软正在使用.NET扩展已有的产品，并且微软不希望承担重新编写.NET代码的开销。为什么我们需要重新编写完美的代码呢？.NET代码可以与已有的代码交互操作，而且你也打赌说我们将利用交互操作能力层添加那些最好的受控代码提供的新特性。我前面曾经指出过，微软在所有的软件中使用了.NET，从操作系统到开发工具再到Office。
·RG：微软当前的操作系统XP和Windows 2003并不依赖于.NET；而且XP中.NET是一个可选组件。
我的回应：上述观点最多只有一半是事实。Windows XP专业版没有使用.NET框架组件，那是因为.NET框架组件是在Windows XP专业版之后发布的。下面是.NET框架组件发布之后发布的操作系统：
·Windows XP多媒体中心版要求.NET框架组件支持特定的MCE应用程序。
·Windows XP专业平板PC版要求用.NET框架组件处理识别程序(它是一个受控应用程序)。
·Windows Server 200需要.NET框架组件来使用ASP.NET、UDDI服务或Sharepoint小组服务。
·Windows小型业务服务器2003需要.NET框架组件来使用ASP.NET、执行SBS特殊的应用程序，例如远程Web工作室和Backup Snap-in。
关于Longhorn和浏览器应用程序消亡的问题
·RG：我的看法是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将提供丰富的界面，但是ASP.NET和HTML不会离我们而去。它的价值在于，我们可以同时在两个世界中取得最佳效果，为XAML浏览器提供最佳的体验，同时保留与老式计算机的兼容。我们必须注意到，客户端应用程序与服务器应用程序之间是有差别的。服务器市场本身完全不同于客户端/消费者市场。尽管人们在谈论到微软公司垄断了90%的客户端操作系统，但是在服务器市场我们没有达到这个数字。
我们需要与IBM WebSphere、成百上千个的中间件产品、Oracle数据库等等产品和公司进行竞争。如果我们希望取得服务器市场的胜利，我们就必须为建立Web应用程序提供速度最快的、最可靠的、最安全的、效率最高的、客户承担得起的解决方案。谈到浏览器应用程序威胁到微软的时间大约是1996年。Web不是威胁。如果它是威胁，那为什么微软使Web变得难以置信的成功和流行呢？Richard接着说微软这样做的目的是为了客户端的收入。客户端操作系统市场，微软拥有超过90%的占有率，几乎是饱和的。服务器市场才是真正的收入增长点。在收入的问题上，典型的服务器交易需要数千美元，用于支付下面一些部分：
·操作系统
·事务引擎
·中间件
·数据库
根据解决方案的复杂程度，其价格可能从几千美元到几百万美元。服务器产品非常昂贵。如果你查看Web内容管理解决方案，就会发现每个处理器企业级许可的平均价格是50,000美元。我的意思是说，在服务器市场存在大量的收入来源，也受到类似IBM和其它公司的激烈竞争。你知道数据库软件市场的收入是多少吗？你相信有数十亿美元吗？你知道Oracle是排名第二的软件公司，他们的主要收入都来自数据库吗？这只是服务器软件市场中的一个机会而已。回到我的观点，我们完全忠诚于自己的服务器产品，并且要把Windows服务器和ASP.NET变成建立Web应用程序的最好的平台。
关于Longhorn的问题
·RG：我认为使Avalon可用于其它版本的Windows表明微软对Longhorn的销售缺少信心。
·RG：但是微软宣称Avalon将可以用于其它版本的Windows，向我表明他们对Longhorn的升级也不是那么自信，而且如果开发者不能确定客户端是否会运行Avalon应用程序，那么他们就不会为Avalon编写应用程序。
我的回应：形成Avalon可用于其它版本Windows的决定是由一个原因--用户需要--所驱动的。所有基本的Web研究都发现顾客抱怨下层操作系统中没有这种功能。
关于在产品中使用.NET框架组件的问题
·RG：因此，从去年的声明中可以看出，微软认为Longhorn并不是在PDC 2003上取得我们信任的伟大的.NET变革。这表明微软正在逐步对.NET失去信心。
我的回应：Richard，你在的文章中提到的Longhorn的关键部分--Avalon和Indigo--都是用受控代码编写的。当我们决定把赌注押在建立在.NET框架组件之上的下一代操作系统的成功的时候，怎么会表明我们对.NET失去了信心呢？你可能会争论说并非整个操作系统都是用受控代码编写的，这就是我们已经"失去了信心"。但是这是你的观点，我不认为受控代码适合于所有情形，而且微软也从来没有这样说过。微软仍然完全支持C/C++，我们拥有非常大的C/C++代码基础和大批C++顾客。我们只在适当的时候使用受控代码。
·RG：它的框架组件变成了Visual Basic--它是供用户开发应用程序的，而不是供微软建立操作系统或建立他们所依赖的带来收入的产品的。
我的回应：我避免回复那些对VB的抨击，因为有些人已经这样做了。我要指出两点，第一是使用.NET框架组件建立操作系统的问题，第二是微软的收入问题。在用.NET框架组件建立操作系统的问题上，我从来都没有说过你应该在单独的受控代码上建立操作系统。事实上，我们大量的客户不会建立操作系统。对于那些需要建立操作系统的或者需要那个层次的控制和性能的客户来说，我们拥有C/C++，而且我们绝对没有抛弃它。至于收入来源的问题，我已经列举了几个使用.NET框架组件带来收入的应用程序。微软被分成了如下所示的几个业务部门，让我们来看看哪一些在使用受控代码：
·Client (客户)- 使用了
·Information Worker (信息工人)- 使用了
·Server & Tools (服务器和工具)- 使用了
·Home and Entertainment (家庭和娱乐)- 使用了
·MSN - 使用了
·MBS - 使用了
·Mobile and Embedded Devices (移 动和嵌入设备)- 使用了
我希望这些内容可以消除那些对受控代码的半真半假的报道和误解。如果有什么不对，请告诉我！
