失去信心？还是再度迷惘

Eric Liu, 2006 年 3 月 16 日 凌晨 2 点于京城

对于最近沸沸扬扬的讨论，相信大家对于 NET expert: Microsoft is losing confidence in .NET 已经有所耳闻，一向支持 .NET 的技术专家 Richard Grimes 的突然反戈在本来就不平静的技术社区掀起了轩然大波。有些戏剧性的是战火是在 TSS.COM 而非 TSS.NET 挑起的，作为 .NET 社区开发人员，可以说是一种悲哀，除了可以归结为 Java Fans 的无聊之作揖外，看来更多的是我们需要去反省自己的思维是否如 Java 社区般的活跃。

我的朋友 孟岩 先生也写了名为《 .NET 面临信任危机，根源在于目标模糊 》的个人评论，总体来说他将 .NET 的遭遇的信任危机归结于微软自身对于 .NET 战略的定位模糊导致。 2004 年我曾经写过一个长篇的 .NET 战略探讨《 在蹉跎中一路前行 》，个人总体认为 .NET 经历了一个狂热到迷惘、再到务实，然后一步一步走向成熟的过程。 2004 年写那个 Post 的时候期待是 2005 年中 .NET 迎来成熟应用的鼎盛时期。

坦白而言，没有我期待中的那样顺利，就如同 Longhorn 一次又一次的裁减功能，一次又一次的推迟发布日子那样让人急不可耐。 Richard 老兄看来也是经受不了这样的煎熬，所以在 DDJ 抛出了那样令人惊世骇俗的论调，一时之间 Java vs .NET 的争端再起，微软为了挽回一些。。。。。。。。。。。。。， Visual C# 的项目经理 Dan Fernandez 也对此作出了自己的 回复 ，我无意去卷入这场没有结果的纷争，去评论 Java or .NET 的孰优孰劣唯一能够得到的是加剧凉两派的怒火。对于 Java 或者说 J2EE ，我的了解太过有限，所以也不敢轻易下什么结论。对于 .NET ，对于微软，因为曾经工作的关系，相对有些了解，因此下面的文字仅仅是针对 Richard Grames 的文章和 TSS.COM 上面相关的讨论有些自己的理解。不是 Microosft 的卫道者，也不是抨击者，谨代表个人意见

Everything rewriting in .NET is Stupid ？

我似乎想不出任何理由需要微软去 .NET 去重写所有的代码，尤其是 Office 这样的产品，已经拥有了那么成熟稳定的版本，假如组织人力使用 .NET 重新编写，除了可以去宣传微软的大款和愚蠢之外，我似乎找不到更好的词语去送给他们了，好在微软还不是那样的傻瓜。已经拥有一个非常能够给他们带来远远不断财富的“造钱工具”，重新编写仅仅是为了炫耀？

有人说 .NET 是一个虚拟操作系统，在我理解的范围内绝对不是如此的，相反，微软是希望通过 .NET 的推广将更多的开发人员绑定在 Windows 操作系统之上，一些最重要的类库如 ASP.NET 、 GDI+ 等等都需要调用操作系统特有的 API 来实现的（相信大家对于 win98 下面无法运行 asp.net 有所了解），对于一些平台出现的问题，微软的文档给以的解释是“需要使用到某些底层 API ”。 OK ，漂亮而邪恶的解释，你尽管可以抱怨原先的 Win32 API 怎么不好用，可以抱怨 MFC 设计的太糟糕，但是莫要忘记了一切都是微软给你提供的编程接口，那么 .NET 做什么呢？首先是做一个包装，让你可以更加方面的进行应用开发， Richard 说的一点都不假， .NET 的很多类库都是从 VB 和 MFC( 应该更多的是 WFC) 迁移过去的，如果大家有兴趣去看看 System.Web.Mail 这个命名空间的类实现，如果利用一些反射工具如 Reflector ，你就可以意外的看到这个所谓的邮件类仅仅是 CDO.Message 的包装，假如没有 cdont.dll 和 cdosys.dll ，你的 MailMessage 没有理由能够很好的工作。这样的情况在 .NET 类库中是很多可以看到的，包括 Richard 提到的 EventLog 。

请不要抱怨 Microsoft 欺骗了你，永远不要去相信商业产品的所谓百分百，基于向下兼容和保护已有类库的应用，微软没有理由要整个 .NET 类库用 C# 或者 VB.NET 这样的语言来编写，我们不要去讨论可以不可以，首要考虑的是必要或者没有必要，答案一目了然， NO 。

微软对于后续产品都提供 .NET 的托管包装是一种临时性的策略问题，从营销的角度考虑，微软需要有一个统一的“ .NET Inside ”去给以开发人员足够的信心，但是在他的能力范围之内，不太可能对于 2000 之后发布的产品都“ Embed .NET ”，所谓 .NET 的 COM+ 互操作和 P/V Invoke 技术一半是给开发人员提供的，一半是留给他们自己用的，因为从商业的角度而言，他们需要有一个统一的技术去完成基于 COM/COM+ 应用的系统能够平稳的迁移到他希望的 .NET 平台。从技术的角度而言呢，微软提供的一些托管包装如 Office 2000 的互操作类库等更多的是为了给 .NET 开发人员提供一个访问既有系统的入口。对于宣传的初期，有了这些技术和宣传的概念，对于这个庞大的“ .NET 战略”而言已经足够，因为大多营销人员花时间去给客户解释“ What’s .NET ”上面去了。

上面提到了 .NET CLR 算不上一个真正意义的 VM ，因为这个 VM 太多的工作只是完成了对于 Win 32 的 API 封装和抽象，一些核心技术还是构建在原有的技术如 COM+,MSMQ 等等之上，在 .NET 世界里这些东西仅仅是盖头换面成 Enterprise Services,Messaging 等等不同 Namespace 下面的托管类，那么谁都知道真正改变的有多少，至于 ASP.NET 和 ADO.NET 还有一些其他技术，那么就另当别论了。那么你会问我 CLR 干么，对于微软征服世界的基础是将所有的应用全部绑定在 Windows 操作系统之上，而 .NET CLR 则让这一些变得更加自然，因为大多开发人员会更加开发 windows 程序更加简单方便，更加“爽”，爽到后面的结果就是不想用其他技术了 J

不同于 Java VM 设计的初衷就是能够独立于操作系统之上提供服务， .NET 从这个角度来看更加是一个寄生的“ VM ”。很多人抱怨 .NET 没有一个类似于应用服务器的概念，如果你接受过微软一些工程师的培训或者听过他们的演讲，他们会振振有辞的告诉你， .NET 是有应用服务器的，因为 Windows 本身就是应用服务器，如群集、故障转移、负载平衡、事务、异步消息等等都是在操作系统层面上提供的。从设计的理念来看， .NET 和 Java 是完全方向的， Java 实现是首先设计了 VM ，然后在 VM 的基础上创建应用服务器，因此所有构建在 Java 之上的应用都是可以在应用服务器之间进行迁移的， OK,.NET 是首先构建了应用服务器，然后 .NET CLR 提供了对于应用服务器的访问包装，你也可以说这些应用服务都是可以迁移的，对，在应用服务器之间进行迁移没有任何问题，对了，我差点忘记了， .NET 的应用服务器是 Windows 操作系统，那么对不起，只有在 Windows OS 之间迁移你的应用了。

这就是微软最本质的 .NET 策略，一个提供了对于 Windows 良好包装的运行时（不是框架），那么对于成熟的产品非得一定要用 .NET 重写吗？包装已经完全足够，重写略显多余，可惜在一些包装上微软到目前依旧没有作的很好， Exchange 是一个很好的例子。

Rewritting in .Net is stupid?

VB.NET is not VB?

不知道在这点上，有多少人可以赞同我的看法，我不敢去妄下结论 VB.NET 的推出是因为技术的考虑还是因为市场的考虑。在 Windows 开发中， VB 和 VBScript 应该属于一个无处不在的语言了，作为一个顶尖的 Windows 开发人员，你喜欢也好，厌恶也罢，但是有一点你不得不承认，如果一点都不会这种可以不声明变量的语法，注定要接受一些煎熬，假如你需要写一些 Windows 脚本程序，假如你要操作 Office, 还有很多假如 ….. 虽然很多人鄙视做 VB 的开发人员，因为他们认为大多 VB 程序员都是不入流的，只是会用 VB 的 IDE 拖放几个控件，然后双击集中的按钮编写所谓的 click 事件。

假如你对于 VB 的理解仅仅停留于此，那么我只能够说你确实不懂这门语言，你看见的仅仅是迷雾，而不是令人仰止的高山。 VB( 这里说 Visual Studio 6 的 VB) 准确的说是一门 Component-Base 的语言，它从语法的角度不提供继承机制的实现，但是提供了一些有效的多态实现，让开发人员能够随心所欲的开发基于组件的应用，如果不是出于性能的考虑，开发 COM 组件没有太多使用 VC （我不是说标准 C++ ）这样设计的略显晦涩的语言，那些有点蹩脚的宏和事件映射相信让追求美感的程序员不止一次的鄙视。在一些业务应用开发方面， VB6 已经登封造极，但是不以为这它没有任何缺点，因为解释执行（虽然 5.0 以后提供了 VB6VM.dll[ 似乎是这个 ] ，但是本质上来说还是解释执行）的效率低下和一些东西太死，让一些顶尖的 VB 程序员束手束脚。

没有人能够准确的指出 VB 的发展应该是怎样的，应该在语言层次上做怎样的扩展，包括微软在内，也不是能够那么一针见血的指出开发人员的真正需要。所以 VB.NET 推出的时候，大多人是失望的，因为发现除了 Dim obj as ObjectType 和 Begin…End 这样语法的接近， VB.NET 已经不是他们想象的 VB ，是的，加入了继承，加入了重载，加入了很多很多关键字，但是我们依旧发现这不是我们要的 VB.NET 。所以当我因为手误创建了 VB.NET 的工程时，我一点都不感到失望，依旧很随手的去写一些需要的测试代码，除了语法结构，我已经没有任何需要去考虑这是一个怎样的语言。

但是对于微软而言，意义远远不止是失望两个字。我想 Richard 的观点是正确的， VB.NET 的推出是为了稳定和巩固 MS 开发人员， 2000 推出 .NET 的时候，在市面上从事 Windows 开发的程序员大多使用 VB6 和 Delphi, 当然还有一部分高高在上的 VC6, 推出 C# 的原因无非是要创造一个没有历史包袱的语言，使其能够更好的胜任基于 .NET 的开发，同时提供类似 C++ 的语法，使 C++ 或者 Java 程序员更快的转到 C# 开发上来。这几年来因为 Borland 的不争气，出人意料的吸引了许多原先的 Delphi 开发人员，而 VB 开发人员要么固步自封，要么干脆抛弃 VB 直接转移到 C#( 国内这样的程序员多一点，在北美市场， VB.NET 还是比较多 ) ，因为 VB.NET 和 VB 的太不接近，对于大多人而言以其去接受一个有历史包袱和阴影的语言，倒不如放开手脚，去学习 Anders 打造的全新语言。

那么这个时候 VB.NET 还是多少的 VB ？

未完待续 …….

后面话题

** Mono only is Mono,not .NET

**

讨论 Mono 和 .NET 的关系

** Losing confidence in .NET?

**

讨论微软失去信心的迹象？

** What’s Microsoft

**

我理解的 Microsoft

** The future of Longhorn

**

对于 Longhorn 的理解，包括定位，还有及其子系统 Indigo,Avalon

** Back to .NET

**

回到现实，讨论如今的 .NET