分享
 
 
 

.NET 神话

王朝c#·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

.NET 神话

Visual Studio.net 的发布已经有近半年了,Windows .net Server RC1 也已经发表了,老比倾力打造的 .NET 天堂即将全面完工。在 M$ 不遗余力的宣传之下,仿佛软件开发即将“跑步进入共产主义”了。

然而不论是对老比和 M$ 而言,还是对广大开发人员来说,这个天堂即便不是远在天边,情况也好不到哪里去。从 .net 诞生之日起就没有什么利好消息出现:广大 J2EE 阵营的厂商加大了宣传力度,对 .net 鼓吹的 SOAP/WebService 也很快就都支持了;尚在 .net/J2EE 之间观望的,仍然还在观望; Gartner 发出警告说移值到 .net 代价太高,风险太大(这大家也是有目共睹的);就在 Windows .net Server RC1 发布前, M$ 也公开承认 .net 并未获得预期的成功。对于开发人员来说,情况也好不到哪里去。

首先来看看 .net 所谓的多语言支持: .net 号称能够支持非常多种语言,只要有相应的编译器把它编译成 IL 即可在 .net 的 CLR 上运行。的确如此,但事实上目前常用的语言如:C++, Object Pascal, Java, VB, PB 等在语法上的差别并不是本质的问题,只要精通一门语言,学习其它语言的语法并非难事,提供这种跨语言的能力用处并不太大。

问题在于每种语言的运行库上,每种语言都有其相应的开发工具,而这些开发工具提供了功能强大的运行库(类库)支持,这些才是关键。简单举例: C++ Builder 的程序员可以很容易地转到 Delphi 上,但转到 VC 上则很难,因为 C++ Builder 和 Delphi 都是用的 VCL ,但 VC 却是用 MFC 。所以相对于语言的迁移来说,库的迁移才是最难的,但 .net 就要求所有在其上运行的语言都使用 CLR 所提供的类库。表面上看 .net 是要为所有的语言提供一个公共的运行环境,但实际上却是一种美国式的“世界单极化”霸权在软件开发上的充分表现。一旦所有的语言都迁移到 .net 平台下,就将失去自己,最后只会剩下一种语言: C# ,因为只有它才是 CLR 类库的绝配,其它语言不过是在效颦。这就是 M$ 的目的。

然而 M$ 的算盘打得未免太如意了一点,梦想是美好的,现实是残酷的。作为开发人员来说,熟悉一种类库是一个非常漫长而痛苦的过程,而包罗万有的 CLR 类库又是一个巨大无比的类库,对每一个有经验的开发人员而言,转到 .net 上开发,其代价和风险都是非常大的。这也就是为什么 vs.net Beta1 刚推出时 VB 程序员一片怨声载道的原因,因为 VB.NET 除了语法上跟 VB 一样以外,用起来完全不是那么一回事。唯一对 .net 有利的是新的开发人员,他们没有其它类库上的开发经验, .net 也许会是他们的选择。还有就是对于 ISV (独立软件开发商)而言,要他们选择放弃当前使用的语言和类库,转到 .net 平台下可能性也是很小的。即使这种转移是必须的,我相信大多数 ISV 会选择更为成熟的 J2EE ,毕竟公司不同于个人,迁移所带来的风险一旦造成损失要比个人大得多。目前也有一些 ISV 在用 .net ,但那更多的是出于市场的目的,沾点 .net 的光可以省很多广告费,毕竟有 M$ 在那为 .net 烧钱吹喇叭呢。

再来看看 CLR/IL :这绝不是什么新概念,只要稍加分析便知其原理与 Java 如出一辙。 M$ 的说法是 CLR 会把编译成 IL 的程序再编译成 COM 来运行,但现在很多 JVM 都支持 JIT 编译,在性能也不会有太大的出入。目前 CLR 只能在 Windows 平台上运行,其各方面都不能跟 Unix 平台(Java 在 Windows 下性能不太好,要在 Unix 上才有好的表现)相提并论。我曾见过一些人对此不服,其实这是很明显的: Windows 主要运行于 IA (Intel 架构)上, Intel 的 CPU 并行能力有限(据说其 CPU 只支持 2 路 SMP , 2 路以上都是主板实现的),除非在 Alpha 平台上, Windows 才能很好地享受多路 SMP 。而 Unix 可以在各种数十路的机器甚至更多的 Mainframe 上运行,负载能力非常的强。我也见过有人说,那 Windows 可以通过 Cluster (集群)技术实现更强的负载,而可靠性比 Powerful 的 Unix 机器高。后来我从微软的技术人员那了解了 Windows 的 Cluster 后才知道原来也不过如此,目前 Windows 2000 Advance Server 支持双机 Cluster ,Windows 2000 Data Center 也只支持 4 机 Cluster 而已,远不能和 Mainframe 之流相比,更何况 Unix 也能 Cluster 。

还有就是 ADO.net :这是抄来的,没什么好吹的,无状态数据库访问在 Borland 的 MIDAS 3 中就已经实现了, ADO.net 的 DataSet 的离线数据集的概念也是来自于 Borland 的 ClientDataSet ,只是 ADO.net 对它进行了一些发展,如:在 DataSet 中可以存在多个数据表等。最糟糕的一点是, ADO.net 与以前的 ADO 不兼容(就这一点,我咨询过微软的人),而且 ADO.net 是属于 .net Framework 的一部分, ADO 2.7 只是 .net 下用的 ADO ,非 ADO.net (这我也向微软全球技术中心的人咨询过)。这就意味着如果用 .net 来写多层的服务端,那么客户端也必须安装 .net Framework 。当然,相对以前的 ADO , ADO.net 是一大进步,但对于以前用 MIDAS 的开发人员来说,并没有带来太大的好处。

还有一个关于.net的神话是: .net 能够解决 DLL Hell 问题。大概是我孤陋寡闻,在 .net 之前我从未听说过 DLL Hell ,直到后来 .net 的消息满天飞的时候我才注意到原来用 DLL 还存在这样的问题。但仔细一考察,问题还是出在 MS 身上, MS 仗着 Windows 是他自己开发的,随意在其中使用和分发各种 DLL ,却不好好处理其兼容问题,看看你的机器里有多少个不同版本的 MSVCRT.DLL 就知道为什么用 VC 写的程序比较小了。更糟糕的是 Windows 用的 DLL 也是如此,相信因为 ComCtl32.DLL 而造成显示异常的问题大家应该也都碰到过吧。终于到了 .net , MS 下决心来解决这个问题了。但同样也是这个 .net ,我在安装 Visual Studio.net Beta 2 时终于碰到了这个著名的 DLL Hell :我原来装的一个与 HTML 有关的程序本来运行很正常的,自从安装 VS.net 后出现了 XXX.DLL 错误了,把 Windows 安装盘中的原来的相应 DLL 覆盖回来, VS.net 就报一样的错了。呜呼, .net 就是这样解决 DLL Hell 的吗?不得已,我只好不用那个软件了。

接着来看看 VS.net 的安装吧:首先, .net Framework 是不能不装的,在装这个东东时,我首先就想到了 Windows 3.x 时代的 Win32S 。不知道时隔八年,还有多少人记得这个东东,当年 MS 将它作为 Windows 3.x 到 Windows 9x 之间的一个过渡,而 MS 就是利用它将其它很多的竞争对手挤出市场的,不知道现在的 .net Framework 是不是又想故技重演,幸好“狼来了”是可以说两次的。而这个 .net Framework 还不够可恨,可恨的是它居然把 IE 6 给装上了,我一直很反感 IE 6 ,我已经碰到它给我带来的两个大麻烦:一是浏览某些用 Lotus Notes 做的页面时显示异常,甚至会造成访问 Notes 的邮件系统发送邮件时发生附件出错的情况。二是它修改了 Windows 的资源管理器中的目录树,将它设置成 RowSelect ,即只要点中某个目录所在的行即可选中此目录,这简直让人要发疯!

然后来看看 VS.NET 本身的安装吧,我是在装正式版的时候碰到问题的,当时我忘记关闭防病毒实时监控(后来才发现是这个原因造成),安装到最后一张一盘(第四张)的时候出现“注册汇编组件{xxxx-xxxx...}(这是一个GUID)时发生错误,错误号:-21xxxx”,我不知道有多少人能看得明白这是什么错误?而且它没有给人重试的机会,只有一个确定,然后就是回滚安装(它的回滚安装倒还算清得干净)。后来我好不容易想到这可能是一个 HResult 值,所以特地写了一个程序来看看这个 -21xxxx 到底是何方神圣,结果一看,四个汉字:“拒绝访问”。那个笨安装程序!直接显示出来不就得了,只是一个 API 函数就搞定的事,我算是服了 MS 的专家们了。

最后来看看 ASP.net :这也许是 .net 中唯一最值得称道的了, ASP.net 在性能上与 JSP 不相上下(在 Windows 平台下 ASP.net 还要好些),而 VS.net 中的 WebForm 开发技术则是目前最有生产力的 Web 开发技术。并且它将页面显示与处理逻辑完全分开,这样比 ASP 或是 JSP 都要好得多。 WebForm 还提供了很多 ServerSide 组件,使 ASP.net 开发和 RAD 几乎一模一样。它也许能够让 .net 首先在 Web 应用领域打开一些局面。即便如此,过多的 ServerSide 控件的使用是不是可能造成过多不必要的网络 RoundTrip ,限制了其在 Internet 上的应用,而只能在 Intranet 中表现?

说了这么多 .net 的不是,大概会被 MS 的拥趸们用板砖给埋掉吧,但这也不能改变 MS 的这次造神运动的事实。我也不是想证明 .net 一无是处,但它也决没有 M$ 说的那么好。如果你要作技术选型的工作,请三思。

[Mental Studio]猛禽 Aug.18, Aug.25-02

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有