从2002年发布.NET 1.0,历经8年发展,.NET发展到了4.0,已经成为一个庞大而复杂的软件开发与运行平台,其架构日益复杂,其应用领域也在不断地扩展,包容了“一堆”的子技术领域。在.NET 4.0即将发布之际,回顾一下已发布的各项.NET技术,看看哪些技术用得很火,哪些被打入冷宫,再猜猜.NET 4.0中可能会有哪些技术会得到“青睐”,是件有意思的事。
在.NET桌面应用程序开发领域,Windows Form是“前辈”,相比以前的老祖宗MFC,其开发效率高得多,即使比一向以“高效率”著称的VB、Delphi之类,也不逊色,因此在很长的一段时间内,Windows Form成为.NET 桌面领域的主流技术,而且有一大批各式各样的第3方控件,其功能可谓应有尽有,使用方便。
Windows Form的问题是“千人一面”,要想做出“与众不同”的界面,真得费不少力气。
.NET 3.0中出现的WPF,在界面设计和用户体验上比Windows Form要强得多,比如其强大的数据绑定、动画、依赖属性和路由事件机制,都非常棒。然而,WPF最头痛的是性能,另外,在需要快速开发原型的场景,WPF暂时还比不上Windows Form方便。
.NET 4.0中,WPF在性能上有较大的改进,这点在使用WPF开发的Visual Studio 2010上体现极为明显,Visual Studio 2010 CTP和BETA1只能用“惨不忍睹”一词来形容,BETA2就有一个性能上的飞越,但还是不是地玩点“崩溃”、“挂死”的把戏,而当前的RC版本,我觉得其使用体验已经超越了VS 2008。
我认为,WPF取代Windows Form是必然的。
(1)ADO.NET。这不用多说了,在实际开发中用得太多了,事实证明了它的成功。
(2)LINQ。
这也是个很大的领域,里面最牛的是LINQ to Object,我一用就喜欢上了。
LINQ to XML也很好,它把程序员从代码中解放出来,可以完成大部分XML存取功能,让大家很高兴有机会能和原先.NET所提供的“一堆”XML相关类说声“不见”。
LINQ to DataSet。作为一个ADO.NET技术的补充,这是一个无足轻重的小卒子,在开发中可以用,也可以直接忽略。
LINQ to SQL和ADO.NET实体框架。这两个技术功能重叠,基本上让人怀疑其中有一个是不是“没有存在的必要”,所以曾有“LINQ to SQL已死”的传言。当然,后来微软公司表态说仍然会继续开发LINQ to SQL的后续版本,争论平息。
但我个人觉得,在实际开发中还是使用ADO.NET实体框架更合适。LINQ to SQL有的功能它都有,而且用起来更为灵活,难得的是它的使用并不比LINQ to SQL复杂多少。
ADO.NET实体框架还延伸到了其它的技术领域,是一项重要的基础数据存取技术。
因此, ADO.NET实体框架 vs LINQ to SQL,前者胜出。
(3)WCF Data Service。
这是一项非常值得关注的技术,原先叫ADO.NET Data Service,它体现了“数据是一种服务”的思想,让数据可以通过HTTP请求直接获取,它设计了一套URI模式,可以完成投影、选择、分页等功能,用起来方便灵活。
我觉得在SOA大行于世的分布式系统时代,WCF Data Service应该会得到应用。
但这一技术问题在于性能。由于数据需要走互联网,所以如果网速很慢的话,基于此技术搭建的应用程序其用户体验将“惨不忍睹”。而且,互联网服务安全问题非常关键,保证基于WCF Data Service技术搭建的应用程序数据安全,想必将成为开发者最费脑筋的地方。
(4)WCF RIA Service。
这个技术与Silverlight密不可分。我还没有系统地了解这一技术领域,不予评说。
这一领域,没说的,ASP.NET中的Web Form是当之无愧的主流。经过多年的发展,Web Form已高度成熟。VS 2008中加入的AJAX系列组件,如ScriptManger、UpdataPanel之类,再配合一堆的应用了AJAX技术的控件,让Web Form更是如虎添翼。基于这种成熟技术开发Web网站,不管是用户还是开发企业,都比较放心。
从.NET 3.5 SP1开始,Web领域多了些新东西。
(1)ASP.NET MVC。MVC这一设计模式已有多年的历史,也有很多的成熟的框架,但在.NET“官方”平台上,却是个新加入的“成员”,并不算成熟,我觉得其应用前景要看看再说。我不知道业界是否已有基于此技术开发的实际项目,有这方面项目经验的朋友,不妨谈谈自己的看法。
(2)ASP.NET Dynamic Data。这是一个看上去很酷的技术。当使用它来创建网站时,Visual Studio 2010会帮你创建一个DynamicData文件夹,里面放了数十个模板文件,构建了一个网站的“脚手架”,几乎不用编码,就可以生成一个全功能的“CRUD”数据驱动网站。
它的设计思想很好:底层使用ADO.NET实体框架或LINQ to SQL构造数据模型,通过提取数据模型中的元数据,动态选择合适的模板生成网页。这就避免了真实项目中不得不为每个数据存取任务设计不同网页的负担,而且这一技术提供了很多的方式去允许你定制网站。
我当初刚一接触时,也很兴奋,这是个好东西啊!但后来我改变了看法,这一技术的问题在于它过于“自动化”了,而且需要包容数十个文件,让其与现有的ASP.NET网站集成相当不便,配置起来麻烦。
我个人认为,在现有.NET Web开发技术应用现状之下,任何一个与现有的ASP.NET网站(以Web Form+AJAX为主体技术)集成麻烦的技术,都很难有“美好”的前途。很不幸,ASP.NET Dynamic Data是这样的例子,ASP.NET MVC也有同样的问题,但没有ASP.NET Dynamic Data严重,而且ASP.NET MVC架构清晰,还是比较易于维护。
(3)Silverlight。这实际上是另一种Web应用架构的代表技术,其立足点在于充分利用客户端的计算资源,可以大大地降低对服务端的依赖,而且易于构造良好的用户体验,我个人认为其发展大有可观。是一个需要重点关注的技术。
.NET 4.0引入了一个“Managed Extensibility Framework(MEF)”,我在此郑重推荐!
MEF通过简单地给代码附加“[Import]”和“[Export]”标记,我们就可以清晰地表明组件之间的“服务消费”与“服务提供”关系,MEF在底层使用反射动态地完成组件识别、装配工作。从而使得开发基于插件架构的应用系统变得简单。够酷的技术!
另外,请忘记.NET 3.5所引入的“MAF(Managed Add-in Framework )”吧,MAF引入了一个复杂的宿主与插件间的通讯管道架构,仅仅是创建一个最简单的SayHello宿主和插件,你也必须创建多达8个项目!
最要命的是MAF设计者“想”得过多,设计了复杂的接口和类继承体系,而且选择让插件运行于与宿主不同的应用程序域中,这就使得插件与宿主之间的通讯变得复杂。个人认为,这些实在不是一个好的设计决策。
我估计,MAF会“无疾而终”。
其实这是一个不需要讨论的问题,有了WCF,我还要Remoting干什么? 因为前者包容后者的所有功能,而且还提供了更多。
WCF的问题是微软企图用一个框架解决所有的问题,因此其架构非常复杂,任何一名想探究其底层运行机理的人,都必须要有足够的心理准备和耐心。
我们可以看到WCF向其它领域的渗透,比如前面的WCF Data Service,还有Workflow Service(将工作流发布为WCF服务),看来微软是将“宝”押在WCF上了,凡是带有“服务”字样的,微软都有把它改造为WCF服务的冲动。
因此,WCF是不得不学习和掌握的技术。
关于并行计算,我已经写过不少文章了,废话少说,在多核时代,我认为.NET并行计算中的任务并行库和并行LINQ,会得到较多的应用。
这个技术,我看是微软自己把事弄砸了。工作流从.NET 3.0开始引入,到.NET 3.5已经比较完善了,也有了一些实际的应用。但.NET 4.0就来了个另起炉灶,WF4与WF3.5相比,简直是另一个产品,而且WF4的BETA1和BETA2相比,居然在对象模型上也有大的改动,RC版本中的WF4我还没看,不知又有什么变动,应该不会再变了吧?!
对于这样一个“变色龙”,谁用谁胆大。
函数式编程很有趣,VS 2010中F#成为.NET正式成员。F#中的许多特性,比如不可更改(immutable)的数据结构,声明性编程风格,强大的类型推断,所有东西都是表达式等,都让习惯了面向对象风格的程序员感到新奇。
我个人觉得,F#如果用于开发多线程并行计算程序,会有较高的开发效率,而函数式编程的特点,也会使它在科学计算中有较好的表现。但用于开发CRUD之类的MIS系统,至少目前还是免谈吧。
Visual Studio 2010集成了云计算开发的项目模板。
云计算是一个说不完的话题。微软在这方面投入巨大。它精心打造了Azure这个云计算平台。了解Azure的最佳方法是看“DAVID CHAPPELL”的文章《INTRODUCING WINDOWS AZURE》,这篇文章可以在微软网站上找到。
虽然我个人认可云计算是一个大的发展方向,但对于中国,这个技术是一道远方的亮丽风景,仅供观赏。因为国内还没有一个成熟的云计算平台,而微软的Azure目前又没有开放中国大陆的云计算购买服务,加上中国又有特殊的国情,所以一切都只是空中楼阁。
云计算真正应用于国内,诸位请继续等待吧。
引自:http://blog.csdn.net/bitfan/archive/2010/03/03/5341985.aspx