失去信心？还是再度迷惘

最新推荐文章于 2024-09-18 19:35:32 发布

liuruhong

最新推荐文章于 2024-09-18 19:35:32 发布

阅读量1.7w

点赞数

分类专栏：业界评论《程序员》杂志文章标签： .net vb.net 应用服务器 vb microsoft windows

本文链接：https://blog.csdn.net/liuruhong/article/details/320576

版权

业界评论同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

《程序员》杂志

9 篇文章 0 订阅

订阅专栏

失去信心？还是再度迷惘

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打造的全新语言。