第二章组织模式
模式不仅依赖于它所包含的更小模式，同时也依赖包含它的更大的模式。它是描述复杂软件的系统方法。
本章的目标是让我们了解以下问题：
1、如何标识模式与模式的关系
2、如何把模式组织成模式集合
3、如何采用不同抽象级别去划分模式
4、如何使用模式解决系统中涉及到的各个方面
5、如何用模式描述解决方案
模式与模式
模式能够描述关系。采用面向对象设计的软件都是有类组成，如果抛开类与类间的关系，模式将什么问题也不能解决。模式把一组类组织成便于管理的模式集合。
我们设计系统时，会发现使用的模式比使用的类都多，那么如何理解模式的作用呢？关键问题是理解项目间的关系。模式与模式的关系比较密切，因此在组织模式是按照关系去组织。
模式集群
我们很容易从一种模式转换到另一种模式上，但我们还不知道如何在系统中使用这些模式,或者应该学习哪些模式。因此这就引起了另一个概念，那就是模式集群。模式集群是涉及特定主题的一组模式的集合。通过模式集群，我们能了解到模式与模式是如何组合，是如何去构建企业级解决方案。模式集群分为5大类，分别是：
集群类型 解决的问题
Web表示 创建动态网站
分布式系统 解决在不同计算机或进程间通信的问题
部署 解决分层应用程序部署到分级硬件上
性能和安全 为某些重要的特定操作提供可靠的保障机制
服务 使用外部服务和对外提供服务
不同级别的抽象
将模式划分为群集方便管理，如构建Web前端只要从Web群集入手就可以。但不同人在项目的不同阶段，感兴趣的方向也不同。如开发人员喜欢Page Control模式，而体系设计人员喜欢分层(Layer)模式。因此我们从抽象级别上对模式进行分类，便于不同人查找自己感兴趣的方向。传统上，使用抽象级别把模式划分为3类，分别是：
体系结构模式：主要描述软件的基础结构，会提前设定子系统或组建间的关系、准则、行为以及职能。例如层(Layer)模式
设计模式：优化子系统或组建间的关系。主要解决在上下中反复出现的问题。例如MVC设计模式、单件(Singleton)模式
实现模式：特定于某种语言或平台的设计模式，如Microsoft.Net的Page Control模式
视点
代码不能全部反应解决方案中的各个方面，比如硬件、网络和部署等方面，因此需要有与设计模式相对应的名称，因此引入视点的概念。视点不描述层次结构，而只是提供看待事情的不同方法。从软件体系上一般分为四个视点，分别是：
1、 数据库视点：是软件的持久层，用于存储数据
2、 应用程序视点：是解决方法的可执行部分，包括域模型、类、程序集、进程等
3、 基础结构视点
4、 部署视点
模式框架
作为参考点和导航助手随每个单独的模式提供描述，同时把各种有意义的子类别组织模式的集合。模式框架有如下特定：
1、 联机事物处理:管理事务处理的数据库子系统，为业务处理提供原子操作
2、 面向对象
3、 分层应用程序
4、 分级分布系统
使用模式描述解决方案
受到约束的模式框架及其所包含的模式提供了足够多的数据点，以便开始使用模式来描述整个解决方案。实际上，第 1 章中的报价示例可以用模式术语来描述。回忆一下，其要求中指定了一个基于 Web 的报价应用程序。描述解决方案体系结构的用户可能会做如下表述：
首先让我们在抽象的体系结构级别看一下这个报价应用程序。从应用程序视点，报价应用程序是面向对象的应用程序，它在逻辑上构造成Three-Layered Services Application. （三层服务应用程序）。从数据库视点，应用程序是基于 OLTP 处理模型的。从基础结构视点，硬件和网络体系结构是基于 Four-Tiered Distribution（四级分布）的，这要求 Web 服务器功能和应用程序服务器功能具有不同的物理级。最后，从部署视点，小组已经基于复杂的 Web 应用程序创建了一个Deployment Plan （部署规划），以便将组件映射到服务器。
这从所有这四个视点向熟悉参考模式的读者简述了解决方案的体系结构。继续向下移动一个抽象级别，可能会看到作者这样描述系统设计：
从应用程序视点，让我们分别考虑 Three-Layered Services Application（三层服务应用程序）的每一层。
表示层是围绕基于Model-View-Controller (MVC) 的 Web 表示框架构造的。 尽管 MVC 将业务层和表示逻辑层分开了，但是每一页都包含大量公共逻辑。为了消除这种冗余，我们使用 Page Controller 来呈现公共头和尾注信息并为用户设置友好的显示名称。
业务层包含客户、报价、订单、系列物品和库存域对象。由于开发速度是一个重要要求，因此这些域对象是使用 Table Module（表模块）实现的。复杂的 Web 应用程序 Deployment Model （部署模型）要求 Web 级和应用程序级分开。因此，这两级通过一个代理程序进行通信。业务实体充当 Data Transfer Objects，用于封装在这两级之间传送的信息。
数据层使用 Data Table Gateway来访问 OLTP 数据库子系统，并使用大量数据访问组件来支持域对象的持久性要求。
从基础结构视点：为了满足业务的操作要求，我们通过添加Load-Balanced Cluster （负载平衡群集）和Failover Cluster（故障转移群集）来基于基本的 Four-Tiered Distribution（四级分布）模型构建。为了满足高级别并发用户的要求，我们在 Web 级中添加了负载平衡功能。为了满足可用性要求，我们在数据库级中添加了群集。
可以继续描述位于同一抽象级别的数据和部署视点。为此，再向下移动一个抽象级别，可能会看到作者这样描述解决方案的实现：
让我们从应用程序视点来查看解决方案。解决方案是使用 Microsoft .NET 技术构建的。表示层基于 ASP.NET 中内置的 Web 表示框架。ASP.NET 使用内置的代码隐藏页功能来简化 Model-View-Controller 的实现。我们使用 ASP.NET 中内置的 Page Controller 机制来实现表示逻辑。业务层中的域对象是 .NET 托管对象。因为表示层和业务层部署在不同的级上，所以我们使用服务器激活对象通过 .NET Remoting 实现 Broker。最后，数据层基于 .NET Framework 中的 ADO.NET 类来提供数据库访问。Table Modules（表模块）和业务实体是使用 ADO.NET 的数据集组件构造的。数据访问组件的其余部分由 Microsoft Application Blocks for .NET 构建块提供。
从基础结构视点：Microsoft SQL Server? 运行在故障转移群集中，用于 OLTP 数据库子系统中。Microsoft 网络负载平衡群集在 Web 服务器之间提供负载平衡。
所有这些会话都经常参考各种模式。最初，这可能有点让人望而却步，但当您了解所使用的模式后，就会认识到即使是一个简短的描述也会让您详细了解系统是如何工作的。请注意，您不必翻阅大量文档或逐步执行无穷无尽的代码行，即可对此有所了解。设想一下在不使用模式的情况下描述解决方案而需涉及到的工作，就不难知道模式所带来的沟通好处。