NET Framework升级的挑战

开篇：润墨网以专业的文秘视角，为您筛选了一篇NET Framework升级的挑战范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

net的重要地位使得每一次fr8mework版本的都引起巨大的关注，同时NET的架构师也不得不应对每一次变更带来的挑战。

从2002年微软．NET framework1.0以来，到现在微软一共了5个版本的．NET Framework：．NET FX 1.0、NET FX 1.1、，NET FX 2.，0NET FX3.0和，NET FX 3.5(Beta 2)。同时还了针对移动设备开发的：．NET Compact Framework 1.0和．NET CompactFramework 2.0。

NET Framework新版本的不断推出，新特性不断增加，需要支持的开发工具也不断升级，对于企业内部的平台构架师来说，也面临着各种抉择：如何规划开发技术策略，如何进行开发技术选型，如何既保持技术的持续性又能充分应用新技术来提

高生产力。NET FX 1．13--2．0――从初

生到成熟。

2002年，微软．NET Framework1.0，这给软件开发界带来了很多激动人心的特性：

统一的类型系统，基础类库，垃圾回收，多语言支持。

ADO．NET 1.0开启了微软全新的数据访问技术。

ASP．NET 1.0对古老的ASP的变革，提供一种全新的方式来开发Web应用程序。 Windows Forms 1.0把微软开发Windows桌面系统的界面统一在一起。

在，NET 1.0之后，很多企业开始转向，NET 1．O的开发。从此软件开发界开始被带上了，NET的道路，同时也不得不面对．NET Framework升级所带来的挑战。

微软在经过3年的研发后，于2005年底了，NET 2．0，这次的变化是革命性的。而架构师们也不得不再次进行抉择和调整：

1．ADO．NET 2.0力口强了很多功能，提升了性能，能够更好的胜任数据层的开发。尤其Visual Studio的Dataset设计器中TableAdapter的功能可以支持可视化设计数据层，让开发数据层更加容易。对于以数据为中心的软件系统，再也无需使用ORM等辅助工具来开发数据层了。

2．Web Service性能得到提升，并且辅以WSE 3.0，安全性等各方面都得以保证。Web Service作为首选的分布式技术成为可能。

3．泛型和内置泛型集合的支持，和其他基础类库的扩展，可以让内部的公共类库开发更加简化。

4．全新事务机制(system・Transactions)的引入，让整个系统的事务处理更加方便。

NET FX 3.0――四大金刚

2006年底，微软了一个稍显另类的版本一一，NET 3.0。这个版本的特殊之处在于，它需要．NET 2.0安装后才能运行。这是因为．NET 3.0是基于．NET2.0基础上而开发的一套扩展包，它增加了如下组件：

Windows Communication Foundation(WCF)

Windows Workflow Foundation(WF)

Window s P re sentationFoundation(WPF)

Windows CardSpace(W CS)

NET 3.0提供的这些新组件为开发企业应用程序提供了一致的基础框架，这样业务开发人员就只需要专注于业务问题的解决，按照.NET 3.0的规范来编写业务代码。平台构架师面对．NET 3.0，需要考虑的就是如何把．NET 3．0提供的这四个组件，融合到企业现有的开发框架中，以及如何和第三方类似的产品进行协作。

WF：支持基于工作流的应用程序

工作流引擎不是什么新技术，但WF的初衷是在Windows环境中提供一个通用的工作流技术，为所有基于工作流的应用程序提供统一的创建基础。

WF支持人员(Human)工作流和系统(Sytem)工作流，也支持连续(Sequential)工作流和状态机(StateMachine)工作流。WF提出了一个重要的概念：活动(Activity)，并同时内置了一个基础活动库(Base Activity Library)，另外开发人员也可以通过API来自定义自己的活动。

WF利用和Visual Studio集成的可视化设计器来设计工作流过程模型。开发好的工作流过程模型可以运行于WF提供的运行时引擎(Runtime Engine)中。在工作流执行过程中，WF也提供了一系列运行时服务来完成额外的工作，如持久支持工作流的长期运行，跟踪功能获取工作流执行过程的信息。

在WF推出后，平台构架师面临的问题是：WF不是工作流管理平台，仅仅是一个工作流的开发基础和执行引擎，并没有提供组织架构图、窗体与流程设计等套件。所以，平台构架师需要做出如下的抉择：基于WF构建自己的工作流管理平台，还是继续使用第三方的工作流平台？是否需要选用基于WF开发的第三方的工作流平台？如何把WF和现存的工作流平台集成?如何由现存工作流平台移植到WF？

WCF：支持面向服务的应用程序

WCF是微软为了统一目前，NET下多个分布式计算技术而提出的，它提供一致的编程模型，通过稳定的结构、极大改进的功能性和互操作性以及可扩展性，全面改善了分布式软件系统的。WCF不仅仅是对以前技术的整合，更多是提供面向服务开发的基础。

WCF的核心思想是服务(Service)，一个服务可以暴露一个或多个端点(Endpoint)，端点即客户端可以使用的接口。而端点由著名的ABC构成：地址(Address)指定发送消息的目标位置、绑定(Binding)描述如何发送消息、合同(Contract)描述消息所包含的内容。客户端只有获知ABC的信息，才能正确访问服务。

使用WCF，有如下优势：

统一的模型。

互操作性，WCF的基本通讯机制是SOAP。

安全性、可靠性和事务，完善支持WS各类规范。

兼容性，WCF可以和旧技术实现的系统进行交互。

WCS：一致的数字标识用户控件

Windows CardSpace，最初的代号叫InfoCard，是微软取代用户ID和密码成为验证网络使用者身份的新方法。实际上就是一项以用户为中心的身份识别技术。用户可以通过它控制登录网站时提交的信息，这将会使管理个人信息更加简便安全。同时这项技术也将包含在WindowsVista之中。微软推广它的目的就是取代传 统的用户名和密码，因为它可以提供更好的反钓鱼功能，并且预防其他类型的网络诈骗。

WCS实际上是一个标识元系统，可以支持任何数字标识系统，而发行、获取和使用数字标识的过程可以视作是获取三个不同角色的过程：

用户：有时称为主体，用户是具有数字标识的实体。

标识提供者：标识提供者可以为用户提供数字标识。

依赖方：依赖方是一个应用程序，以某种方式依赖于数字标识。

WCS为这三种实体在标识元系统中进行交互提供了一致的环境。

wPF：适用于不同用户界面的

统一方法

用户界面对于应用程序是极其重要的一个部分，随着IT业的发展，用户对界面的要求越来越高。但是在．NET下一直存在着多种界面开发方式：使用Win-dows Forms开发Windows桌面软件界面，使用ASP．NET开发Web应用程序界面。另外，很多应用程序还需要嵌入文档、视频、实现2D和3D动画。这样，开发人员为了实现不同界面，需要学习不同的技术。是否有一种统一的技术来同时满足不同的需求？

WPF(最初的代号为“Avalon")就是为解决这一问题而设计。WPF为所有的这些用户界面提供一致的技术基础，从而大幅简化了开发人员的工作。WPF采用更为现代的方法，支持视频、动画、二维或三维图形以及各种类型的文档，从而可以让用户以全新的方式处理信息。此外，WPF还为桌面客户端和浏览器客户端提供了通用基础，大大简化了二者的应用程序开发工作。

在开发用户界面的过程，人们还遇到一个重要的问题就是：界面逻辑的开发人员，并不擅长定义界面的外观和交互设计。而界面设计人员并不熟悉IDE等工具。因而，界面设计人员和开发人员很难协同工作。为了解决这个问题，WPF引入名为XAML(可扩展标记语言，一种基于XML的语言，允许以声明方式指定用户界面，而非代码)的技术来分离界面定义代码和界面逻辑代码。

WPF给应用程序的界面开发带来的变化是巨大的，可以说WPF代表了未来界面技术的方向。然而在目前的情况下，WPF并没有大规模运用，也没有成为主流，因而平台构架师面临的问题就有点尴尬：既无法把WPF作为唯一选择，也无法很好解决当前界面开发的一些疑难杂症。也许，最好的选择就是：尽量把界面层独立出来，让开发团队开始学习wP F，并逐步尝试使用WPF。

NET FX 3．5――语言的变革

微软将于今年年底，NET Frame work 3.5，目前大家已经可以获取8月份的Beta 2版本。值得说明的是，Beta2已经附带了Go-Live的许可协议，这说明整个．NET 3.5的接口已经冻结。对于一个超前的团队，完全可以把．NET 3.5运用于实际的项目开发了。

NET 3．5有如下3个方面的重要新特性：

ASP．NET AJAX，NET 3.5把之前的Ajax扩展包内置到．NET 3.5里面。

语言改进和LINQ，具体改进有：自动属性、对象初始化器、集合初始化器、扩‘展方法、Lambda表达式、查询句法、匿名类型。

LINQ t0 SQL实现的数据访问改进。

ASP．NET AJAX几乎不会刁难平台构架师，因为Ajax已经流行很长一段时间，ASP．NET Ajax扩展包已经在大量使用了，．NET 3.5带来的唯一好处就是无需单独部署以前的Ajax扩展包了。

语言方面的改进，引入了函数式编程(Functional Programming)的思想，但不会对整个系统构架和企业内部的开发框架产生多大的影响，只会让开发人员编写代码更加灵活和敏捷。

LINQ(Language Integrated Query)，通过编译器来实现在语言中类似SQL的查询语法，是一个跨时代的底层技术，它的出现让语言能力变得无比的强大。

而LINQ to SQL却给平台构架师出了难题：在ADO．NET和LINQ to SQL中如何选择？在第三方ORM和LINQ toSQL如何选择？在LINQ t0 SQL和未来的ADO．NET EF(Entity Framework)中如何选择？

对于第一个问题，由于LINQ t0 SQL和ADO．NET一样是对数据库结构的映射，那么基于LINQ t0 SQL来开发数据访问层和ADO．NET的基本做法也大同小异，唯一不同的是LINQ to SQL面对的实体和实体集合，对数据处理无需编写SQL语句。

对于第二个问题，当前版本的LINQto SQL还仅支持SQL Server，还不足以成为真正意义上的ORM。如果你只使用SQL Server，并且对ORM的要求不高的话，使用LINQ to sQL来代替现有的ORM是可行的。

第三个问题提到的ADO．NET EF是一个实体或概念设计的服务框架，是将现实的实体和实体间的关系映射到对象层，目的是能够更好地支持流行的Domain Model Driven的开发。而LINQ to SQL是和数据库紧密绑定的，无法进行抽象也无法支持多级的继承，更偏重语言层面对数据库的操作。所以说，是选择未来的ADO．NET EF还是LINQ to SQL完全取决干应用系统的规模和设计模式。