.NET架构与模式探索

位于不同级别的模式

　　模式存在于多个不同的抽象级别中。考虑另一个示例（这次所处的抽象级别比源代码要高一级）：

　　您要设计一个基于Web的报价应用程序，其中包含大量业务和表示逻辑，这些逻辑反过来依赖大量平台软件组件来提供适当的执行环境。如何在高级别组织系统以使其在具有灵活、松耦合性的同时仍具有高内聚性？

　　此问题的解决方案之一涉及到按一系列层来组织系统，每层包含大致位于同一抽象级别的元素。随后，确定每一层中的依赖性，并确定采用严格还是宽松的分层策略。接着，决定是打算创建自定义的分层方案，还是采用以前由其他人记录的分层方案。在本例中，假设您决定使用众所周知的分层策略：表示、业务逻辑和数据访问各占一层。图2显示了分层方案的可能外观。

图2 报价应用程序的层

　　如果您总是按这种方式设计系统，说明您已经在不依赖于任何广义模式的情况下使用该模式。即便如此，您还可能因多种原因而希望了解支撑这种设计方法的模式。您可能迫切想知道为何经常以这种方式构建系统，或者可能在寻找更理想的方法来解决此模式不能完全解决的问题。使用层作为高级别组织方法是Layers（层）模式[Buschmann96]^[3]中描述的完善模式。图3显示了该模式的简化版本。

图3 简化的Layers模式

　　这个简单的应用程序组织策略有助于解决软件开发中面临的两个挑战：依存关系的管理和对可交换组件的需求。如果在构建应用程序时没有一个考虑周全的依存关系管理策略，会导致组件易损坏且不牢靠，从而导致对它们进行维护、扩展和替代时存在较大的困难，而且成本较高。

　　Layers模式中的工作机制比Singleton中的工作机制更精细。对于Layers，首次协作是在设计时发生在类之间，这是由于分层组织将对更改源代码所带来的影响局部化，从而防止所做的更改贯穿到整个系统。第二次协作发生在运行时：某层中相对独立的组件变得可与其他组件交换，再一次使系统其余部分不受影响。

　　尽管Layers模式的通用性足以应用于诸如网络协议、平台软件和虚拟机之类的领域，但是它无法解决企业类业务解决方案中存在的某些特定问题。例如，除通过分解来管理复杂性（由Layers解决的基本问题）外，业务解决方案开发人员还需要进行适当组织，以便有效地重复使用业务逻辑并保留与昂贵资源（如数据库）的重要连接。解决此问题的方法之一就是使用Three-Layered Application（三层应用程序）模式。图4显示了该模式的简化说明。

图4 简化的Three-Layered Application

　　同样，在模式(Three-Layered Application)和模式应用程序（报价应用程序分层模型）之间存在区别。模式是有关应用程序组织主题的通用问题-解决方案对，而模式应用程序是通过创建具体的层来解决非常具体的问题。

　模式的优化

　　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不是第一个体现架构和模式的软件应用平台，确是目前为止最后的实现了架构和模式的平台，在随后的文章介绍中，你将会发现，架构设计和模式应用会是如此简单。

　　[1] 《软件体系结构（影印版）》，科学出版社2004年1月1日出版。Mary Shaw、David Garlan合著，原文书名《Software Architecture: Perspectives on an Emerging Discipline》。

　　[2] GoF95，《设计模式——可复用面向对象软件的基础》，Erich Gamma、Richard Helm等著，英文版本《Design Patterns: Elements of Reusable Object-Oriented Software》，这是设计模式领域的经典之作，它结合设计实例从面向对象的设计中精选出23个设计模式，总结了面向对象设计中最有价值的经验，并且用简洁可复用的形式表达出来。

　　[3] [Buschmann96] Buschmann，Frank，《Pattern-Oriented Software Architecture》，John Wiley & Sons Ltd，1996。中文版《面向模式的软件体系结构》，2003年1月机械工业出版社出版。

查看本文来源