模式的优化 

    Three-Layered Application实际上是在Layers的基础上进行的简单优化；在Layers中确定的上下文、影响因素和解决方案仍适用于Three-Layered Application，但反之不行。也就是说，Layers模式约束着Three-Layered Application模式，而Three-Layered Application模式优化了Layers模式。

    您为某个发展迅速的成功企业构建了一个报价应用程序。现在，您希望通过向业务合作伙伴公开自己的报价引擎并将其他合作伙伴服务（如配送）集成到该报价应用程序中来扩展该应用程序。您将如何构造自己的业务应用程序以提供和享受服务？

    此问题的解决方案之一是通过将其他与服务相关的职责添加到每一层中来扩展Three-Layered Application。在业务层添加了以下职责：通过Service Interfaces（服务接口）向客户应用程序提供一组简化的操作。数据访问层的职责拓宽到了数据库和主机集成之外，以包括与其他服务提供者的通信。将数据访问层中的这个附加功能封装到服务接口组件中，这些组件负责连接到服务（同步和异步）、管理服务的基本会话状态并向业务流程组件通知与服务相关的重大事件。

    Three-Layered Services Application（三层服务应用程序）（图5）记录了该问题-解决方案对。

图5 简化的Three-Layered Services Application

    将Three-Layered Services Application模式应用于报价应用程序示例将形成如下模型。

图6 应用于报价应用程序的Three-Layered Services Application

    请注意这些模式之间的关系（请参阅图7）。Layers引进了一个用来组织软件应用程序的基本策略。Three-Layered Application优化了此概念，并将它限制在需要重复使用业务逻辑、灵活部署和高效使用连接的业务系统的范围内。Three-Layered Services Application又在Three-Layered Application的基础上进行了优化，并对设计进行了扩展，以便在提供和使用其来源千差万别的数据和逻辑时，将这些数据和逻辑处理为粒状元素。

图7 相关模式的优

    向特定层中添加其他类型的组件并不是管理这种日益增长的复杂性的唯一方法。正如复杂性所证实的那样，设计人员通常在应用程序中创建其他层来承担该职责。例如，一些设计人员将服务接口移到一个单独的层中。而另外一些设计人员将业务层分隔成域层和应用程序层。在任何情况下，您有时可能会看到某些设计人员在使用此模式来满足复杂要求时，有时会将这三层扩展到四层、五层或者甚至六层。与之相反，Layers模式也用在相对简单的客户端-服务器应用程序中。

    解决方案简述：术语“解决方案”有两种截然不同的含义：其一是表示模式本身的一部分（如某上下文中包含的问题-解决方案对）；其二是表示业务解决方案。在使用“业务解决方案”这一术语时，它是指专用来满足一组特定的功能和操作业务要求的软件密集型系统。软件密集型系统意味着您不只是关心软件，而且还必须将该软件部署到硬件处理节点以提供整体的技术解决方案。而且，所考虑的软件不仅包括自定义开发的软件，而且包括购买的软件基础结构和平台组件，所有这些都被集成在了一起。

结束语

    以.NET为代表的Microsoft产品线向我们展示了“架构为基础，模式为指导”的企业解决方案设计理念，秉承微软产品一贯以来的简单易用以外，同时我们将看到使用.NET构建企业应用平台上使用.NET的优势。毫不夸张地说，.NET不是第一个体现架构和模式的软件应用平台，确是目前为止最后的实现了架构和模式的平台，在随后的文章介绍中，你将会发现，架构设计和模式应用会是如此简单。