Three-Layered Services Application（三层服务应用程序）

您正在设计 [color=#770000]Layered Application。您希望将应用程序的一些核心功能作为其他应用程序能够使用的服务进行公开，并且希望应用程序能够使用其他应用程序所公开的服务。
[/url]
问题
如何将面向服务的应用程序分层，然后确定每一层中的组件？

影响因素
除了 Layered Application 中讨论的影响因素外，还应考虑下列影响因素：
•
始终希望将尽量减小在现有应用程序中添加服务所造成的影响。
•
服务通常向公司防火墙以外的客户端公开，因此具有不同于业务组件的安全和运行要求。
•
与其他服务通信需了解大量与协议和数据格式有关的知识。
•
希望将关注的问题分隔在不同的组件中，以便仅针对单个原因而更改组件，例如将业务逻辑与访问外部服务所需的技术分隔开来。
[url=http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/ArcThreeLayeredSvcsApp.mspx#top]
解决方案
将分层体系结构建立在三层基础上：表示、业务和数据。此模式概述了每一层的职责以及组成每一层的组件。有关详细信息，请参阅文章"Application Architecture for .NET: Designing Applications and Services." [PnP02].
上面所显示的 Three-Layered Services Application基本上是一个松散的三层体系结构。三层分别是：
•
表示。表示层提供应用程序的用户界面 (UI)。这通常包括 Windows 窗体（用于智能客户端应用程序）和 ASP.NET 技术（用于基于浏览器的交互）的使用。
•
业务。业务层实现应用程序的业务功能。域层通常由使用一种或多种支持 .NET 的编程语言实现的大量组件组成。这些组件可能为实现可伸缩的分布式组件解决方案而以 Microsoft® .NET Enterprise Services 进行了扩充，或者为实现工作流编排而以 Microsoft BizTalk® Server 进行了扩展。
•
数据。数据层提供对外部系统（如数据库）的访问。该层涉及到的主要 .NET 技术是 ADO.NET。但是，在这里也经常用到一些 .NET XML 功能。
每一层应当按下面各段落所述进行构造。
表示层
大多数业务应用程序都使用窗体来构造表示层。应用程序由一系列用户与之交互的窗体（页面）组成。每个窗体都包含许多用于显示较低层的输出以及收集用户输入的字段。
实现基于窗体的用户界面的两类组件是：
•
用户界面组件
•
用户界面处理组件
用户界面组件
对于富客户端应用程序，此模式使用 .NET Framework 的 System.Windows.Forms 命名空间中的 UI 组件。对于 Web 应用程序，此模式使用 ASP.NET 组件。如果标准 .NET 组件不能满足您的需要，.NET 还支持标准 UI 组件的子分类，并支持将您自己的自定义组件插入到框架中。
用户界面处理组件
复杂的用户界面通常需要许多非常复杂的窗体。要增加可重用性、可维护性和可扩展性，可以创建单独的用户界面处理 (UIP) 组件，以便封装窗体之间的依赖性以及与窗体之间的导航关联的逻辑。其中的部分概念适用于一个窗体的组件之间的依赖性、验证和导航。这些 UIP 组件通常是基于 Front Controller、Application Controller [Fowler03] 和 Mediator [Gamma95] 等设计模式的自定义组件。
UI 和 UIP 组件之间的交互通常遵循 [color=#770000]Model-View-Controller或 Presentation-Abstraction-Controller [Buschmann96] 模式。
业务层
大型企业应用程序通常是围绕业务流程和业务组件的概念构造的。这些概念是通过业务层中的大量组件、实体、代理和界面来处理的。
业务组件
在 Business Component Factory 中，Peter Herzum 和 Oliver Sims 对业务组件的定义如下：
自治业务概念或业务流程的软件实现。它包含将指定的业务概念作为较大型分布式信息系统的自治、可重用元素来表示、实现和部署所必需的所有软件制品。[Herzum00]
业务组件是业务概念的软件实现。在业务应用程序的生命周期中，它们是设计、实现、部署、维护和管理的主要单元。业务组件封装业务逻辑（也称业务规则）。这些规则约束业务概念的行为以匹配特定公司的需要。例如，确定某个指定客户是否被批准进行某项借贷活动的业务规则可以封装在小型解决方案的客户业务组件中。对于大型解决方案，所有与借贷有关的业务逻辑可能都封装在单独的一个借贷组件中。
注意：Three-Layered Services Application 不同于 Herzum 和 Oliver 定义的地方在于，业务流程组件形成了它自己的类：业务工作流组件。
业务工作流
业务流程反映了业务执行的宏观级别的活动，例如，订单处理、客户支持和原料采购。这些业务流程由编排一个或多个业务组件以实现业务流程的业务工作流组件封装。例如，ProcessOrder 业务工作流组件可以与 Customer、Order 和 Fulfillment 业务组件交互，以执行"处理订单"业务流程。可以使用任何 .NET 语言来开发自定义的业务工作流组件。或者，也可以使用 BizTalk Server 来定义业务流程，并自动编排业务组件。
业务实体
业务实体是数据容器。它们封装并隐藏特定数据表示格式的细节。例如，业务实体最初可能封装从关系数据库中获得的记录集。之后，可以修改该业务实体，以便在编写 XML 文档时尽量减少将对应用程序余下部分所产生的影响。
业务和业务工作流组件可以与独立的业务实体组件交互，或者使用业务实体以便设置它们自己的状态，然后丢弃该业务实体。业务实体通常用作 Data Transfer Objects [Fowler03]。数据访问组件通常返回业务实体，而不是数据库特有的结构。这非常有助于将数据库特有的细节隔绝于数据层中。
服务接口
应用程序可以将它的部分功能作为其他应用程序可以使用的服务进行公开。服务接口将该服务呈现给外部世界。理想情况下，它隐藏实现细节，并只公开粗粒度的业务接口。服务接口通常使用 XML Web Service 实现。
如果您使用的是域模型，那么您的域模型中的类通常由一个或多个域层组件实现。
数据层
大多数业务应用程序必须访问存储在公司数据库（最常见的是关系数据库）中的数据。此数据层中的数据访问组件负责将存储在这些数据库中的数据公开给业务层。
数据访问组件
数据访问组件将业务层与特定数据存储解决方案的细节隔离开来。这种隔离具有下列优点：
•
尽量减少数据库提供方的更改所造成的影响。
•
尽量减少数据表示的更改（例如，数据库架构的更改）所造成的影响。
•
封装操作单个位置的特定数据项的所有代码。这极大地简化了测试和维护过程。
ADO.NET 可以直接用作简单应用程序的数据访问组件。通过 ADO.NET 开发一组用于管理对象-关系映射复杂性的类，对于更复杂的应用程序很有益处。
服务网关
业务组件通常必须访问内部和外部服务或应用程序。服务网关是封装使用此类服务所必需的接口、协议和代码的组件。例如，业务解决方案通常需要记帐系统中的信息才能完成业务流程。解决方案会将与记帐系统的所有交互委派给服务网关。服务网关使得更改外部服务提供方变得更为容易。服务网关甚至可以模拟外部服务，以使域层的测试变得容易。
基础服务
除了三个标准层，Three-Layered Services Application 还定义所有层都可以使用的一组基础服务。这些服务分为三个基本类别：
•
安全性。这些服务维护应用程序安全性。
•
运行管理。这些服务管理组件以及关联的资源，并满足可伸缩性和容错等运行要求。
•
通信。这些是提供组件之间的通信的服务，如 .NET Remoting、SOAP 以及异步消息传递。
[url=http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/ArcThreeLayeredSvcsApp.mspx#top][/url]
结果上下文
使用 Three-Layered Services Application 模式具有下列优缺点：
优点
此模式规定的三层是您设计自己的解决方案的良好起点。您在继承 Layered Application 模式所具有的大多数优点的同时，还可尽量减少必须跨越过多层所造成的负面影响。
缺点
对于复杂的解决方案，可能有必要进一步划分域层，尤其是在重用性具有很高的优先级，或者要基于常用的一组组件设计一系列解决方案时，更是如此。在这种情况下，通常用下列三层来替换此模式中描述的一个业务层（有关详细信息，请参阅 Larman02）：
•
应用程序。应用程序层包含对于应用程序具有唯一性的业务组件。
•
域。域层包含业务域内常见的业务组件。例如，与保险、能源或银行业有关的组件。
•
业务服务。业务服务层包含提供常用业务功能（如财务、产品和订单功能）的业务组件。
单一用户界面层对于提供复杂用户界面的解决方案可能不够。例如，数据验证、命令处理、打印和撤消/重复等功能可能需要其他层。