Microsoft.NET的企业解决方案模式.第章.docVIP

第1章　企业解决方案的构建模式 发布日期： 2004-04-15 | 更新日期： 2004-04-15 版本 1.1.0 “我们发现，目前正常工作的复杂系统总是从以前正常工作的简单系统演变而来的……从头开始设计的复杂系统总是不能正常工作，也无法通过修补来使其正常工作。您必须从正常工作的简单系统开始。”— John Gall 发表于 Systemantics: How Systems Really Work and How They Fail 企业级业务解决方案是公司实现其业务的赌注，它们通常极其复杂，而且性能必须不负众望。它们不仅必须具有高可用性和伸缩性以应对不可预知的使用，而且还必须具有适应性和预见性以适应快速变化的业务要求。 最佳解决方案是那些由一组更小的、简单的、能够可靠且有效地解决简单问题的机制组成的解决方案。在构建更大、更复杂的系统过程中，将这些简单的机制组合在一起，从而形成更大的系统 本指南旨在获取经验丰富的开发人员的知识，并以模式目录的形式呈现这些知识。每种模式都包含一个简单的、经过证实可以有效解决小问题的机制。虽然您可以单独理解和运用每种模式，但您还会经常组合这些模式来构建复杂的系统。 模式对于开发人员和体系结构设计者非常有用，因为它们： ? 记录能够正常工作的简单机制。 ? 为开发人员和体系结构设计者提供通用的词汇和分类法。 ? 允许以模式组合的方式简明扼要地描述方案。 ? 允许重复使用体系结构、设计和实现决策。 本章将介绍模式的概念，并解释模式如何记录简单的和经过证实的机制，最后展示模式集合如何为开发人员和体系结构设计者提供公用语言。为了阐明这些概念，本章运用了真实开发情形中实际模式的简化版本。 本页内容 模式可以记录简单机制 常见词汇 小结 模式可以记录简单机制 模式描述给定上下文中反复出现的问题，并基于一组指导性影响因素来建议解决方案。解决方案通常是一种简单的机制，是为了解决模式中所标示出的问题而一起工作的两个或多个类、对象、服务、进程、线程、组件或节点之间的协作。 注意：在这些模式中描述的基础机制虽然概念上很简单，但实际上，它们的实现却相当复杂。实现时，必须具备一定的技能和判断能力，才能对常规模式进行取舍，以适应具体的环境。另外，出于介绍的目的，本章所提到的模式已进行了高度的精简，后面几章将更详细地介绍各种实际模式。 考虑下例： 您正在构建一个报价应用程序，其中有一个类负责管理系统中的所有报价。很重要的一点是，所有报价都应与该类的一个（而且只与一个）实例进行交互。如何构造您的设计，以便从该应用程序中只能访问该类的一个实例？ 解决该问题最简单的方案就是创建一个具有私用构造函数的 QuoteManager 类，以便任何其他类都不能实例化它。此类包含 QuoteManager 的一个静态实例，并使用名为 GetInstance() 的静态方法返回。此代码大体如下所示： public class QuoteManager { //注意：仅适用于单线程应用程序 private static QuoteManager _Instance = null; private QuoteManager() {} public static QuoteManager GetInstance() { if (_Instance==null) { _Instance = new QuoteManager (); } return _Instance; } //... QuoteManager 提供的函数 } 您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题。实际上，注意反复出现的问题并寻求解决方案的模式作者已经屡次发现了这种实现，提取出了通用解决方案并将这种问题-解决方案对称为 Singleton 模式 [Gamma95]。 问题-解决方案对模式 请注意，Singleton 模式不涉及 Quote 或 QuoteManager 类。但其外观有点类似于下面的简化示例。 图 1: 简化的 Singleton 模式 通过将图 1 中简化的模式示例与 QuoteManager 源代码进行比较，阐明了模式（通用问题-解决方案对）和模式应用程序（针对非常具体的问题的具体解决方案）之间的区别。模式级别的解决方案是多个类之间简单但极其顺畅的协作。模式中的通用协作专门适用于 QuoteManager 类，提供了用来控制报价应用程序中实例化的机制。显然，您可以稍微修改一下某种模式以满足局部的特定要求，所以同一种模式可以应用于无数个应