 |
|
|
 首页 |
名片设计 CorelDRAW Illustrator AuotoCAD Painter 其他软件 Photoshop Fireworks Flash |
|
.NET断想 荣耀 2002秋 “遗留软件”和“遗留程序员”是阻碍.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来的更有效率。 究竟，硬件的品质也在不断提升。 返回类别: 教程 上一教程: .NET Framework For Java Programmers ---2（Good） 下一教程: 给开心的：Visual Studio .NET Custom Wizards 您可以阅读与".NET断想"相关的教程: · 转业界评说：DotNet的进一步消息 · 利用 .NET 框架简化发布和解决 DLL Hell 问题 · 使用 Microsoft.NET Frameworks 创建Windows应用程序 · Microsoft Visual Studio.NET及Borland Delphi6初探 · 给Asp.Net初学者的关于继续和多态性的例子 |
  |
| 快精灵印艺坊 版权所有 |
首页 会员中心在线印刷在线编辑付款方式索取样品设计指南连锁门店
|
||
