描述 .NET Framework 3.0
应用程序开发的目标始终如一，就是在最短时间内制作出最好的软件。然而，随着开发平台的性能越来越高，制作软件的壁垒也相应提高了。以 Windows 为例，原来的 Win32 接口已经融入到功能更强的 .NET Framework 中。2002 年发布的 Framework 1.0 和 2005 年发布的 Framework 2.0 为设计和编写 Windows 软件的开发人员提供了更好的工作环境，效率也更高。
。NET Framework 3.0（以前称为 WinFX）就是我们前进路上的下一个目标。建立在这一新版 Framework 上的应用程序可通过 Visual Studio 2005 创建，对大多数 Windows 开发人员来说，这样的应用程序将会更加熟悉。。NET Framework 3.0 是从 2.0 版本演化而来，并在原来的基础上添加了许多新的功能 本文对 .NET Framework 3.0 及其组件进行了整体描述，目的是让大家对这一新版本有一个清晰的了解，同时分析了采用的技术，并给出简要说明。
创建现代应用程序：主要挑战
今天，开发一款优秀的应用程序可不简单 - 您需要考虑众多的要求。传统的考虑因素，如访问数据、通过 Web 浏览器上网等固然重要，但这些已经显然不够了。下面列出了现代应用程序面临的一系列新挑战：
组织越来越倾向于从面向流程的角度看待他们的工作。由于大多数应用程序已经对业务流程实现了部分自动化，因此，在代码中明确流程中的这几个步骤就非常重要了。而要实现这一目标，最有效途径是使用工作流技术，这是一种需要支持基于工作流的应用程序的方法。
通常来讲，应用程序要与组织内外的其他应用程序进行通信。现代应用程序还必须适用于面向服务的架构 （SOA），同时还要实现一些功能，作为其他软件可以访问的交互服务。要实现这些目标，就需要支持面向服务的应用程序。
对于使用应用程序的人员来说，通常还需要有传递识别信息的方法。目前定义和使用数字标识的技术各不相同，这也是造成网页仿冒等问题泛滥的原因。有鉴于此，现代应用程序及其使用者将会从一致的数字标识用户控件中受益。
对于现代用户界面，人们的要求也有了很大幅度的提高。要提供真正的业务价值往往需要处理不同类型的文档，使用二维或三维图形，播放视频等等，还要保证本地 Windows 客户端和 Web 浏览器能够兼容这些功能。要满足这些要求，需要不同的用户界面采用统一的方法。
一般说来，现在的应用程序需要应对以上部分或全部的挑战，因此，这些应用程序的开发平台应该采用一致、可行的方法来解决所有的相关问题……NET Framework 3.0 就是专为解决这些 Windows 应用程序难题而设计。
应对挑战：.NET Framework 3.0 功能介绍
如图 1 所示，.NET Framework 3.0 版是在以前版本的基础上完善而成。事实上，3.0版本保留了 .NET Framework 2.0 的全部功能，因此，在以前版本基础上开发的应用程序仍然可以正常使用。.NET Framework 3.0 添加了四个新组件：Windows Workflow Foundation、Windows Communication Foundation、Windows CardSpace 和 Windows Presentation Foundation。本节将会概要介绍 .NET Framework 2.0 和上述四个新组件的功能。
图 1
·NET Framework 2.0：Windows 应用程序通用基础
尽管仍然可以通过 Win32 界面直接编写软件，而事实上却是，。NET Framework 已经成为编写新 Windows 应用程序的主流环境。如下所示为。NET Framework 最重要的组成部分：
· ASP.NET，支持可 Web 访问的应用程序的开发。
· ADO.NET，允许应用程序访问相关的其他类型数据。
· Windows Forms，支持建立 Windows 应用程序的图形用户界面 （GUI）。
· System.XML，使应用程序能够使用 XML 定义的数据，包括 XSLT 和 XPath.
Framework 的 2.0 版本在以前版本的基础上添加了几项实用功能，包括对开发 ASP.NET Web 应用程序的技术改进，支持在 64 位 Windows 上运行的 64 位应用程序，还增加了处理事务的新方法。虽然 .NET Framework 2.0 中的部分组件为 3.0 版本中新增组件所取代，但是 2.0 版本的技术仍然是新发布的 3.0 版本的基础，请见随后的详细介绍
1.工作流
Windows Workflow Foundation：支持基于工作流的应用程序
工作流是一个简单思路：按照特定顺序执行的一系列步骤。您甚至可以认为每个应用程序都在执行工作流，因为每个应用程序都执行某些过程。但是，在使用 C#、Visual Basic 或其他编程语言等传统方法开发的应用程序中，这些过程都隐含在代码中。这样做没问题，但是这些过程被深深地嵌入程序逻辑中，使得其执行或更改愈加困难。
使用工作流技术执行过程逻辑可以有效地解决这一问题。采用工作流技术后，逻辑与普通代码就不会纠缠在一起，过程中的每一步骤都会明确定义，然后由工作流引擎执行。这样做的结果就是，过程执行清楚明确。
工作流引擎不是什么新概念，有些已经在 Windows 和其他系统中得到应用。Microsoft 已经在部分产品中嵌入了工作流引擎。但是，随着工作流日渐成为开发应用程序的主流方法，提供适用于 Windows 的单一工作流技术已经势在必行。这也正是 Windows Workflow Foundation（正式缩写是 WF ）的设计初衷。由于其提供了适用于 Windows 的通用工作流技术，WF 已成为所有基于工作流应用程序的统一创建基础。Microsoft 的 Microsoft Office 2007 系统、Windows SharePoint Services 等软件，以及许多其他公司的应用程序也会使用 WF.
但是，提供通用的工作流技术之路却是困难重重。举例来说，如何使用一种方法来满足不同工作流应用程序的各种要求？WF 给出的答案是，从全局视角来看待工作流。如图 2 所示，WF 工作流只是一组由 WF 引擎执行的活动。一个活动就是一个类，它可以包含工作流创建者认为有必要的任何工作。活动可以在不同的工作流中重复使用，因此，在针对新问题创建自动化的解决方案时，过程将会更加容易。
图 2
提供通用工作流技术面临另一个困难是，面向人员工作流和面向系统工作流的传统分歧。通常来说，工作人员使用的工作流应用程序需要有较高的灵活性，能够进行实时更改。而一般由系统，也就是由软件使用的工作流应用程序则相对更加静态，但要求尽可能高效。WF 综合考虑了这两种不同的使用情况，不仅包括面向人员的功能（如更改运行中工作流的功能），同时还支持更多面向系统的操作。
通过 WF 的 Windows 通用工作流技术，。NET Framework 3.0 为广大开发人员提供了一种非常有用的软件开发模式。随着面向流程的软件继续风行，工作流技术也会随之推广。
2. Windows Communication Foundation：支持面向服务的应用程序
无论是通过工作流还是其他方式开发，绝大多数应用程序都需要与其他应用程序进行通信。近几年来，应用程序间的通信技术发展迅速。在长达数十年的不统一之后，主要供应商之间最终达成了一致的应用程序通信协议。根据 SOAP 这一全球 Web 服务协议，基于 J2EE、。NET Framework 等不同技术平台开发的应用程序间的互操作性相比以前大为简化。它还会使面向服务的架构这一思想为更多的组织接受。
当然，现在的通信方式已经不少了。以 .NET Framework 2.0 为例，您可以选择以下几种通信方式：
· ASP.NET Web 服务，提供基于 SOAP 的交互通信。
· .NET Remoting，主要用于 .NET 应用程序之间的通信。
· Enterprise Services，支持可扩展的事务性应用程序。
· System.Messaging，通过 Microsoft Message Queuing （MSMQ） 支持队列消息。
· Web Services Enhancements （WSE），它是 ASP.NET Web 服务的扩展，支持 WS-Security 等新规范。
这些技术都有其自身的价值，在实际应用中也有着各自的地位。可是，既然问题是一样的，为什么要采用好几种不同的解决方案呢？为什么不根据交互服务来建立一个单一的应用程序通信基础？
这正是 Windows Communication Foundation （WCF） 的设计初衷。有了 WCF，开发人员不必再像从前一样，处理每一类通信都要使用到不同的应用程序编程接口技术 － WCF （最初的代号为“Indigo”）以通用的 API 提供通用的方法。在 .NET Framework 3.0 环境下，大多数使用上述技术之一的应用程序将会代而使用 WCF.
WCF 通过 SOAP 提供强大的交互通信支持，这是现代计算机设备的基本要素。它还支持多项 WS-* 规范，如 WS-Security、WS-ReliableMessaging 和 WS-AtomicTransaction.WCF 不需要 SOAP，但是可能会使用其他方法，包括优化二进制协议、MSMQ 队列消息 和基于 REST 的简单通信。WCF 同样采取明确的面向服务方法来进行通信。WCF 不会在对象间进行透明通信，而是为通信各方提供略微不同的抽象服务。其结果之一就是放开了分布式对象系统间某些紧密的耦合关系，使得交互出错减少，并且更容易修改。
无论是在组织内部还是组织之间，应用程序通信都是现代软件的基本功能。。NET Framework 3.0 以其 WCF 面向服务方法解决了这一难题
Windows CardSpace：一致的数字标识用户控件
请您想一下，人们在 Internet 上是如何表示各自身份的。多数情况下是将个人的数字标识作为一个简单的用户名。再加上密码之后，就可以使用这个标识访问电子邮件帐户、网上商店、网上银行和其他一些金融机构了。尽管这种方法很简单，现在也在普遍应用，但是用户名和密码方式有着无法回避的缺点。最重要的两项是：
要记住登录众多网站的不同用户名和密码，的确让人不胜其烦。为了减少这些麻烦，许多人在不同网站使用相同的用户名和密码，可这样又增加了安全风险。
用户名、密码和其他个人信息可能会被网页仿冒者窃取。网页仿冒者会发送欺骗性电子邮件，诱使受害者去登录一个假冒网站，比如一个与受害者银行极其相似的仿冒网站。而这个网站实际上是网页仿冒者控制的。一旦受害者输入自己的用户名和密码，网页仿冒者就会利用这些信息，在真网站冒充该用户，牟取不当利益。
要减少这些问题的危害性，我们需要采用新的方法来管理数字标识。Windows CardSpace（最初代号为“InfoCard”）是这种新方法中的重要组成部分。为帮助人们追踪自己的数字标识，CardSpace 用不同的信息卡来表示每个数字标识。如果网站接受 CardSpace 登录，那么用户在尝试登录这一网站时会看到 CardSpace 选择屏幕，如图 3 所示。您可以选择一张卡片，这就相当于选择了登录该网站的数字标识。不必再去费心记住数不清的用户名和密码，用户只要记住他们要使用的那张信息卡就可以了。不同的信息卡还包含其他信息，用户可以通过它控制登录网站时提交的信息。
图 3
信息卡表示的这些标识是由一个或多个标识提供者创建而成的。组织可以有自己的标识提供者，而不必依赖于简单的用户名和密码。每个标识提供者都会采用更加强大的加密机制，让用户来验证他们的标识。CardSpace 本身也包含一个自发行的标识提供者，可以在客户端计算机上运行。使用这一提供程序，用户可以创建自己的标识，且标识也不必依赖密码进行身份验证。网站接受这些自发行 CardSpace 标识，这样就不必再依赖常见的密码方法，自然会减少因密码而带来的诸多问题。
不用密码登录网站，网页仿冒者也就无密码可偷了！但是，如果网页仿冒者成功诱使受害者访问假冒网站的话，他们还是会窃取用户的其他信息，如敏感的医疗信息等。要杜绝这种情况，就要求用户自己能够区别假冒网站和真网站。为帮助用户识别网站，拥有网站的组织应获取“高度确认认证”。与现在的 SSL 简单认证不同，新的认证方式涉及到更多、更严格的流程，其中包括采用更严格的方式来证明申请该项认证的组织的身份。高度确认认证上还可以带有公司徽标和其他信息，帮助用户准确识别使用证书的网站是否合法。用户访问新网站时，CardSpace 会始终以标准屏幕显示该网站的证书信息。根据认证的接受程度，屏幕上会自动显示出对网站标识的确认程度。其目的是，强制用户明确界定网站是否可信，然后帮助他们作出正确选择。
Windows CardSpace 实际上是更大的标识元系统的一部分。标识元系统完全基于开放的公共协议，它定义了一种全新的方式，能够使不同的数字标识技术在各个不同的平台（包括 Windows 以外的操作系统）和应用程序（包括 Internet Explorer 以外的 Web 浏览器）上使用。CardSpace 采取通用的方法来选择标识和其他 Windows 信息，因而在元系统中扮演着重要角色。并且，由于解决了基本的标识问题，CardSpace 也已经成为 .NET Framework 3.0 的重要组成部分。
Windows Presentation Foundation：适用于不同用户界面的统一方法
对几乎所有的应用程序来说，用户界面都是重要的组成部分。现在，用户对这些界面的要求越来越高了。当然，我们仍然需要传统的菜单驱动式 GUI.但是除此之外，许多应用程序还需要能够播放视频、运行动画、采用二维或三维图形，以及调用不同的文档。无论是通过安装的桌面客户端还是通过 Web 浏览器来访问应用程序，上述功能都必须可以正常使用。
一直以来，Windows 上的这些用户界面功能都是以不同方式提供的。例如，开发人员可以使用 .NET Framework 中的 Windows Forms 来创建 Windows GUI，使用 HTML、Java 小程序或 JavaScript 代码创建 Web 浏览器界面，或是使用 Windows Media Player、Adobe 的 Flash Player 等软件播放视频，文档格式则以 Microsoft Word、Adobe PDF 或其他软件进行定义。很明显，开发人员面临着巨大的挑战：如何使用不同的技术，为不同的客户端创建一致的用户界面。这相当困难。
Windows Presentation Foundation （WPF），最初代号为“Avalon”，就是为解决这一难题而设计。WPF 为所有的这些用户界面提供一致的技术基础，从而大幅简化了开发人员的工作。WPF 采用更为现代的方法，支持视频、动画、二维或三维图形以及各种类型的文档，从而可以让用户以全新的方式处理信息。此外，WPF 还为桌面客户端和浏览器客户端提供了通用基础，大大简化了二者的应用程序开发工作。
让我们以图 4 中的界面（其中包含了图像、现场图、三维视图等等）为例说明 WPF 的部分功能。过去，开发人员需要懂得各种技术才能进行工作；而现在通过这种更为一致的方法，开发人员可以轻松制作出类似示例中的用户界面。
图 4
另外一个长期困扰用户界面开发人员的问题是，如何创建高效界面需要的不同角色。软件开发人员需要编写相应的界面逻辑，但是，他们并不是定义界面感观的最佳人选。一般来说，人机交互领域的设计人员和专家更适合这一工作。但是在以前的技术（如 Windows Forms）背景下，这些问题完全由开发人员决定。开发人员和设计人员之间没有实现真正有效的协作。WPF 借助于可扩展应用程序标记语言 （XAML） 解决这一问题。XAML 是一种基于 XML 的语言，允许以声明方式指定用户界面 －而非代码。这就，开发工具就能够根据设计人员创建的可视化显示，更加容易地生成和使用界面规范。实际上，Microsoft 的一款新产品 Expression Interactive Designer 就是为此而设计。使用这一工具（其他的由第三方提供），设计人员可以创建界面外观，然后生成他们所创建界面的 XAML 定义。开发人员将这些定义导入 Visual Studio 之后，就可以着手构建界面所要求的逻辑了。
开发人员创建了直接在 Windows 上运行的安装版 WPF 应用程序后，就可以使用 WPF 提供的全部功能了。但是，若要创建在 Web 浏览器内部运行的客户端程序，开发人员应创建一个 XAML 浏览器应用程序，我们通常称之为 XBAP.与安装版 WPF 应用程序的基本原理相同，XBAP 允许在可下载的浏览器应用程序中表示与用户界面相同的样式。两种应用程序可以使用相同的代码，这也就意味着开发人员不再需要针对桌面和浏览器客户端的不同技术集。特别是按照此类丰富 Internet 应用程序的现状，在安全沙箱内运行从 Internet 下载的 XBAP，将会限制应用程序的功能。但是，安装版 WPF 应用程序中提供的大量用户界面功能子集也可用于 XBAP.
WPF 安装版应用程序和 XBAP 都可以利用 WPF 的现代图形支持，其中包括使用硬件加速、支持矢量图形以及其他更多功能。通过提供更强大的图形支持功能，WPF 使得一系列数据可视化选项成为可能，而这依靠 Windows Forms 或其他的早期技术是不可能实现的。WPF 还提供了 XML Paper Specification （XPS） 的基础，可定义查看、分发和打印固定格式文档的标准格式。
用户界面是现代应用程序中复杂而重要的组成部分。通过 WPF，。NET Framework 3.0 提供了一种比较完整和一致的解决方案，用于应对用户界面方面的难题。其目标是使构建用户界面的相关人员（包括开发人员和设计人员）能够更有效的进行工作。
应用 .NET Framework 3.0：设想
理解一组技术如何协同工作的最好方式，就是查看其使用方式的示例。现在假设，一款应用程序要求客户和代理提交保单。如果使用 .NET Framework 3.0 执行，则会有图 5 所示的工作流程。
图 5
图表左上角所显示的应用程序业务逻辑，是使用 WF 工作流得以实现的。处理保单是一项多步骤流程，包括根据组织的保险规则来评估此保单，或许要检查投保人的信用，甚至还要获得其上司的批准。工作流依靠所需要的其他软件，以活动方式实现流程中的每一个步骤。如果要访问存储数据，工作流中的活动可以使用 ADO.NET.
保险公司可以提供一个呼叫中心，使客户可以通过电话进行投保。呼叫中心员工使用的客户端软件显示在图表的右上角，是由安装版 WPF 应用程序实现的。客户端使用 WCF 与应用程序业务逻辑进行通信，采用的是经过 WCF-WCF 通信优化的二进制协议。如图所示，呼叫中心工作人员依靠 Windows CardSpace 来选择他们在登录该应用程序时将要使用的标识。
客户还可以通过网络进行投保，而保险代理商也可以通过网络提交保单。为便于网络操作，该应用程序使用 ASP.NET 与 Web 浏览器进行通信。如图表的左下角所示，客户通过 Internet Explorer 来访问该应用程序，他们可以使用普通的 HTML 界面，也可以使用 CardSpace 来选择自主设定的标识。第三方也可以为其他客户端操作系统和浏览器实现标识选择机制，使得标识元系统能够扩展至非 Windows 客户端和 Web 浏览器。
保险代理商通过 Internet 访问该应用程序时可能需要具有更多功能的界面。因此，他们应该使用 XBAP 而非简单的 HTML 界面。如图表底部中间位置所示，这些客户可以共享呼叫中心所用 WPF 桌面应用程序提供的大部分用户界面功能。由于两者构建在同一基础之上，因此应用程序开发人员可以在两种类型的客户端中重复使用相同的代码。对于其他类型的客户端来说，代理商可以使用 CardSpace 选择他们针对该应用程序所设定的标识。
最后，此应用程序有可能需要与其他应用程序之间进行互访。如果批准客户时要求信用审核，则最有可能通过调用外部服务实现。或者此应用程序会直接收到外部软件请求，提供这些外部应用程序可以调用的服务。在这些情况下，如图表右下角所示，该应用程序依靠 WCF 使用标准 Web 服务进行通信。无论这些应用程序构建于何种技术之上，WCF 对 SOAP 的支持都使得这些应用程序之间的交互变得轻而易举。
该方案说明了如何使用 .NET Framework 3.0 中最重要的组件来构建出色的应用程序。而此处所举的简单示例省略了相当多的选项，因此不能将其视为该系列技术所有功能的完整说明。相反，该示例只是提供一种思路，用于讲解如何使用 .NET Framework 3.0 的不同部分来解决实际的业务问题
