好贷网好贷款

.NET断想

发布时间:2016-12-3 14:55:37 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了".NET断想",主要涉及到.NET断想方面的内容,对于.NET断想感兴趣的同学可以参考一下。

 “遗留软件”和“遗留程序员”是阻碍.NET普及的最大阻力。另外一个阻力(听起来有点庸俗:))是目前的Windows操作系统没有预装.NET框架。运行.NET应用,你需要另外安装.NET框架,这多少都有点麻烦。COM为何会在极短的时间内迅速取得成功,Windows内建了COM基础设施不能不说是原因之一。      微软当然比谁都清楚这一点,所以,“Windows .NET”系列操作系统,必然指日可待。      假如你对此观点不以为然,不妨看看CORBA在Windows平台上命运。当然了,这只是原因之一,而且,我说过,这个原因有点俗:)      不过在此也要纠正一个谬误。不在少数的程序员以为,在访问以ASP.NET技术创建的Web网页(.aspx)的客户端机器上,也必须安装.NET框架,这个概念是错误的。道理其实很简单 — 服务端总是返回生成的HTML。      无论微软如何宣称,无论.NET如何支持多种语言,都不会影响“C#是.NET最佳语言拍档”。      但在相当长的一段时间内,Visual Basic .NET或许反而会比C#占有更多的用户。原因并不复杂 — 现有的Visual Basic程序员为数众多 — 尽管今天的Visual Basic .NET早已不是从前的Visual Basic了。      Visual Basic程序员过渡到Visual Basic .NET,可能要比C++或Java程序员过渡到C#困难得多。      .NET框架由通用语言运行时(Common Language Runtime,CLR)和.NET框架类库构成。.NET在操作系统之上又加了一层抽象,.NET本身并不是操作系统。      为什么有那么多的人憎恶微软?这很让人费解。无论哪家公司,倘能取得微软这样的成就,都是了不起的。无论谁坐到了微软的位置上,估计都会这样。      憎恶微软的人,要么是微软的竞争对手,要么是非微软阵营的狭隘的开发人员,要么啥也不是,纯粹人云亦云,瞎起哄。      无论你多么憎恶微软,无论你怎样不喜欢.NET,假如你是一名“面向微软”的开发人员,学习掌握.NET只是早晚的事。      假如你是一名Windows开发人员,纵然你从来都不打算使用.NET技术进行实际软件开发工作,想对.NET完全免疫也是不可能的,你至少得知道它究竟是怎么一回事儿。      今后若干年内,.NET和Java将会形成分庭抗礼之势。两大阵营各有支持力量,只有在竞争中彼此学习互补,才能共同前进。任何一方都很难一口吃掉对方。      在软件开发世界,单极世界难免霸道,绝对不会长久;两极世界的平衡很难长时间维持,容易被打破;多极世界是丰富多彩了,但无疑将会成为开发人员的灾难,因为异质技术的整合,从来都是一场噩梦。      Java已经占据了大片地盘,在微软支持下,.NET将会最大限度地把pre.NET开发人员拉向自己的怀抱。在这个过程中,或许有人逃到Java阵营,但人数不会太多。道理很简单,假如你是一名微软技术开发人员,学习.NET所要花费的功夫,无论如何都不应该超过学习Java所要花费的功夫。      在从微软pre.NET技术过渡到.NET过程中,肯定会淘汰掉一些无法与时俱进的开发人员,这是正常现象。在技术进步的过程中,每一次创新,抱残守缺者总是会被毫不留情地抛弃。      自然选择,物竞天择。      有多少人会使用Managed C++?数目应该不会太乐观。相当一部分C++程序员往往会有某种没来由的优越感,对任何非C++的东西不屑一顾,大有万般皆下品,唯有C++高的感觉。在这些C++程序员的眼里,Managed C++已经算不上C++了,或者说,充其量,Managed Extensions for C++不过是微软对C++打的一个.NET补丁而已。      每一个严格符合.NET框架的语言的程序,最终都将被转换为MSIL代码(当然啦,有些语言只是提供了同CLR-based代码交互的能力,并不真的生成MSIL),但这并不意味着使用不同的.NET语言编写的功能相同的代码,将会转换成同样的MSIL代码。编译器的质量会有差别,生成的MSIL代码的质量也肯定会存在差异。      非微软的.NET语言据说已有两打之多,但它们很难成为主流。某些第三方.NET语言的现实意义,不过是提供了一种将现有代码移植到.NET之上的途径而已,另外一些仅仅具有学术研究方面的价值。      我不知道究竟会有多少人在.NET上使用Perl或者Python,尽管今天它们的拥趸的确不在少数。我只能肯定Delphi(Object Pascal)应该是个例外。      能否成为主流.NET语言,主要取决于:是否有足够多的“遗留软件”,是否有足够多的“遗留程序员”,是否有足够好的IDE,是否有实力足够雄厚的组织提供强力支持。      向来只有微软自己的技术才能和微软的技术最佳匹配,COM就是一个例子。COM无疑是pre.NET时代最成功的跨语言机制,但这种技术在跨微软自己的语言(确切地说,是开发环境),比如从Visual C++跨到Visual Basic以及相反时,表现还好,跨到了别的语言(开发环境),比如说Delphi,就会暴露出这样或那样的问题。      但愿类似的情况不会发生在.NET身上,但愿遵循CLS的语言果真可以完美无缝地互操作,就象微软自家生养的.NET语言一样:)      Web Services技术并非微软独创,也不是由.NET带来的,但仍然有相当一部分人误以为它是伴随微软.NET而来的技术。微软推广技术(概念)的功夫,由此可见一斑。      别误会,.NET Compact和.NET框架可以说是很不一样的东西。.NET Compact并不是从.NET框架中简单地砍掉一些东西之后的精简版,否则.NET Compact也不会比.NET框架晚交货那么长时间。      ASP.NET应用程序,就是.NET应用程序。普通ASP开发人员过渡到ASP.NET的痛苦,比起从Visual Basic过渡到Visual Basic .NET所要承受的痛苦(快乐?),不会少到哪里去。      ADO.NET是一种革命性的技术,尽管无可否认,它从Borland借鉴了许多数据存取技术,但ADO.NET对XML技术的支持,目前无疑处于领先地位。      我希望速度不要成为Web Services被广泛应用的阻力。在荣耀编写的一个测试应用中,整合来自不同厂商的Web Services的应用效果是令人惊讶的,不过,这个应用速度之慢,同样出人意料。      或许基于Web(WAN)的分布式计算,迫使我们不得不作出速度上的妥协,就象我们可以容忍(并且已经习惯)浏览器应用比传统Windows GUI应用来得慢一样。      .NET框架应用或许会比那些Windows DNA应用运行得慢,不过,我们真正应该关心的问题并非是这些应用到底能运行多快,而是它们是否足够快,快到可以满足用户业务处理的要求。      Java的成功已经提供了这些证据。尽管Java代码一般来说要比本地代码来得慢,但它还是足够快了,许多组织都非常成功地使用了这种技术。因此,对于.NET速度上的担心,完全是多余。按照微软自己的说法以及第三方提供的一些测试数据,.NET至少比目前版本的Java来的更有效率。      毕竟,硬件的品质也在不断提升。  

上一篇:06年最值得期待的10部华语电影,绝对力作(组图)
下一篇:项目经验-李轶楠

相关文章

关键词: .NET断想

相关评论