分层架构模式 .NET架构和模式

1、分层架构模式:.NET架构和模式疯狂代码 http:/CrazyC :http:/CrazyC什么是架构 软件Software体系结构通常被称为架构指可以预制和可重构软件Software框架结构架构尚处在发展期对于其定义学术界尚未形成个统意见而区别角度视点也会造成软件Software体系结构区别理解以下是些主流标准观点ANSI/IEEE 610.12-1990软件Software工程标准词汇对于体系结构定义是:“体系架构是以构件、构件的间关系、构件和环境的间关系为内容某系统基本组织结构以及知道上述内容设计和演化原理(principle”Mary Shaw和David Garlan认为软件Sof

2、tware体系结构是软件Software设计过程中超越计算中算法设计和数据结构设计个层次体系结构问题包括各个方面组织和全局控制结构通信协议、同步数据存储给设计元素分配特定功能设计元素组织规模和性能在各设计方案的间进行选择Garlan & Shaw模型基本思想是:软件Software体系结构=构件(component,连接件(connector约束(constrain.其中构件可以是组代码如模块;也可以是个独立如数据库服务器连接件可以是过程、管道、远程过程(RPC等用于表示构件的间相互作用约束般为对象连接时规则或指明构件连接形式和条件例如上层构件可要求下层构件服务反的不行;两对象不得递规

3、地发送消息;代码复制迁移致性约束;什么条件下此种连接无效等有关架构定义还有很多其他观点比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型7、Boehm模型等等虽然各种定义关键架构角度区别研究对象也略有侧重但其核心内容都是软件Software系统结构其中以Garlan & Shaw模型为代表强调了体系结构基本要素是构件、连接件及其约束(或者连接语义这些定义大部分是从构造角度来甚至软件Software体系结构而IEEE定义不仅强调了系统基本组成同时强调了体系结构环境即和外界交互什么是模式 模式(Pattern概念

4、最早由建筑大师Christopher Alexander于 2十世纪 7十年代提出应用于建筑领域 8十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件Software领域Christopher Alexander将模式分为 3个部分:首先是周境(Context也可以称着上下文,指模式在何种状况下发生作用;其 2是动机( of Forces,意指问题或预期目标;其 3是解决方案(Solution,指平衡各动机或解决所阐述问题个构造或配置(Configuration他提出模式是表示周境、动机、解决方案 3个方面关系个规则每个模式描述了个在某种周境下不断重复发生问题以及

5、该问题解决方案核心所在模式即是个事物(thing又是个过程(process不仅描述该事物本身而且提出了通过怎样过程来产生该事物这定义已被软件Software界广为接受软件Software模式应用对软件Software开发产生了重大作用主要表现在:软件Software模式是人们在长期设计软件Software、管理组织软件Software开发等实战中大量经验提炼和抽象是复用软件Software设计思路方法、过程管理经验有力工具模式类似于拳击中组合拳它提供了系列软件Software开发中思维套路如通过模式使用有利于在复杂系统中产生简洁、精巧设计软件Software模式为我们提供了套简洁通用设计、管理

6、、组织方面词汇同时模式也为我们提供了个描述抽象事物规范标准标准可大大促进软件Software开发过程中人和人的间交流而软件Software开发中交流是至关重要“软件Software项目失败原因最终都可追溯到信息没有及时准确地传递到应该接收它人”架构和模式关系 架构(Architecture和模式(Pattern在当前软件Software开发中经常地被提及可是很多人容易混淆这两个术语而对此学术界也没有个非常统定义架构和模式应该是个属于相互涵盖过程但是总体来说Architecture更加关注是所谓High-Level Design,而模式关注重点在于通过经验提取“准则或指导方案”在设计中应用因此在

7、区别层面考虑问题时候就形成了区别问题域上Pattern模式目标是把共通问题中不变部分和变化部分分离出来不变部分就构成了模式因此模式是个经验提取“准则”并且在次次实战中得到验证在区别层次有区别模式小到语言实现(如Singleton大到架构在区别层面上模式提供区别层面指导根据处理问题粒度区别从高到低模式分为3个层次:架构模式(Architectural Pattern、设计模式(Design Pattern、实现模式(Implementation Pattern.架构模式是模式中最高层次描述软件Software系统里基本结构组织或纲要通常提供组事先定义好子系统指定它们责任并给出把它们组织在起法则和

8、指南比如用户和文件系统安全策略模型N-层结构组件对象服务等我们熟知MVC结构也属于架构模式层次个架构模式常常可以分解成很多个设计模式联合使用设计模式是模式中第 2层次用来处理设计中反复出现问题例如GOF95整理总结23个基本设计模式Factory Pattern, Observer Pattern等等实现模式是最低也是最具体层次处理具体到编程语言问题比如类名变量名名命名规则;异常处理规则等等相对于系统分析或者设计模式来说体系结构从更高层面去考虑问题所以关注问题就体现在“不变”原因上比如系统部署中更加关心应用分层分级设计而在这个基础的上提出部署方案才是架构考虑重点体系结构关心应用模式更加体现在通

9、过技术去解决这些业务差异带来影响关心是否是分布式应用关心系统分层是如何设计也关心性能和安全因此在这样情况的下会考虑集群负载平衡故障迁移等等系列技术希望通过定义方式来区分架构和模式是不太可能本来就是交互交叉和提供服务它实际上是架构模式而不是设计模式在大部份情况下表现为下面几个设计模式的:Strategy模式、Mediator模式、Composite模式、Observer模式对于熟悉架构设计系统架构师而言似乎可以用如下来解释架构和模式的间关系:架构是Hight-Level Design,着眼于区别业务中共性解决方案而模式是General Principle(通用原理企业解决方案构建模式 企业级业务

10、解决方案是公司实现其业务赌注它们通常极其复杂而且性能必须不负众望它们不仅必须具有高可用性和伸缩性以应对不可预知使用而且还必须具有适应性和预见性以适应快速变化业务要求最佳解决方案是那些由组更小、简单、能够可靠且有效地解决简单问题机制组成解决方案在构建更大、更复杂系统过程中将这些简单机制组合在起从而形成更大系统对这些简单机制认识来的不易它通常存在于有经验开发人员和体系结构设计者头脑中并且是他们潜意识中自然带到项目中重要知识模式对于开发人员和体系结构设计者非常有用它们:记录能够正常工作简单机制为开发人员和体系结构设计者提供通用词汇和分类法允许以模式组合方式简明扼要地描述方案允许重复使用体系结构、设计

11、和实现决策模式可以记录简单机制 模式描述给定上下文中反复出现问题并基于组指导性影响原因来建议解决方案解决方案通常是种简单机制是为了解决模式中所标示出问题而起工作两个或多个类、对象、服务、进程、线程、组件或节点的间协作您正在构建个报价应用其中有个类负责管理系统中所有报价很重要点是所有报价都应和该类个(而且只和个例子进行交互如何构造您设计以便从该应用中只能访问该类个例子?解决该问题最简单方案就是创建个具有私用构造QuoteManager类以便任何其他类都不能例子化它此类包含QuoteManager个静态例子并使用名为GetInstance静态思路方法返回此代码大体如下所示:public Quote

12、Manager/注意:仅适用于单线程应用private QuoteManager _Instance = null;private QuoteManager public QuoteManager GetInstance (_Instancenull_Instance = QuoteManager ; _Instance;/. QuoteManager提供您可能已经像其他许多开发人员那样通过类似方式解决过类似问题实际上注意反复出现问题并寻求解决方案模式作者已经屡次发现了这种实现提取出了通用解决方案并将这种问题-解决方案对称为Singleton模式GOF95问题-解决方案对模式 " a

13、lt=".NET架构和模式" />图1 简化Singleton模式通过将图1中简化模式举例和QuoteManager源代码进行比较阐明了模式(通用问题-解决方案对和模式应用(针对非常具体问题具体解决方案的间区别模式级别解决方案是多个类的间简单但极其顺畅协作模式中通用协作专门适用于QuoteManager类提供了用来控制报价应用中例子化机制显然您可以稍微修改下某种模式以满足局部特定要求所以同种模式可以应用于无数个应用所编写模式提供了种记录简单且经过证实机制有效思路方法模式是以特定格式编写这点对于装载复杂思想容器非常有用这些模式在被记载和起名的前就早已存在于开发人员大脑及

14、其代码中位于区别级别模式 模式存在于多个区别抽象级别中考虑另个举例(这次所处抽象级别比源代码要高级:您要设计个基于Web报价应用其中包含大量业务和表示逻辑这些逻辑反过来依赖大量平台软件Software组件来提供适当执行环境如何在高级别组织系统以使其在具有灵活、松耦合性同时仍具有高内聚性?此问题解决方案的涉及到按系列层来组织系统每层包含大致位于同抽象级别元素随后确定每层中依赖性并确定采用严格还是宽松分层策略接着决定是打算创建自定义分层方案还是采用以前由其他人记录分层方案在本例中假设您决定使用众所周知分层策略:表示、业务逻辑和数据访问各占层图2显示了分层方案可能外观" alt="

15、;.NET架构和模式" />图2 报价应用层如果您总是按这种方式设计系统介绍说明您已经在不依赖于任何广义模式情况下使用该模式即便如此您还可能因多种原因而希望了解支撑这种设计思路方法模式您可能迫切想知道为何经常以这种方式构建系统或者可能在寻找更理想思路方法来解决此模式不能完全解决问题使用层作为高级别组织思路方法是Layers(层模式Buschmann96中描述完善模式图3显示了该模式简化版本" alt=".NET架构和模式" />图3 简化Layers模式这个简单应用组织策略有助于解决软件Software开发中面临两个挑战:依存关系管理和对可交

16、换组件需求如果在构建应用时没有个考虑周全依存关系管理策略会导致组件易损坏且不牢靠从而导致对它们进行维护、扩展和替代时存在较大困难而且成本较高Layers模式中工作机制比Singleton中工作机制更精细对于Layers首次协作是在设计时发生在类的间这是由于分层组织将对更改源代码所带来影响局部化从而防止所做更改贯穿到整个系统第 2次协作发生在运行时:某层中相对独立组件变得可和其他组件交换再次使系统其余部分不受影响尽管Layers模式通用性足以应用于诸如网络协议、平台软件Software和虚拟机的类领域但是它无法解决企业类业务解决方案中存在某些特定问题例如除通过分解来管理复杂性(由Layers解决

17、基本问题外业务解决方案开发人员还需要进行适当组织以便有效地重复使用业务逻辑并保留和昂贵资源(如数据库重要连接解决此问题思路方法的就是使用Three-Layered Application( 3层应用模式图4显示了该模式简化介绍说明" alt=".NET架构和模式" />图4 简化Three-Layered Application同样在模式(Three-Layered Application和模式应用(报价应用分层模型的间存在区别模式是有关应用组织主题通用问题-解决方案对而模式应用是通过创建具体层来解决非常具体问题模式优化 Three-Layered Appl

18、ication实际上是在Layers基础上进行简单优化;在Layers中确定上下文、影响原因和解决方案仍适用于Three-Layered Application但反的不行也就是说Layers模式约束着Three-Layered Application模式而Three-Layered Application模式优化了Layers模式您为某个发展迅速成功企业构建了个报价应用现在您希望通过向业务合作伙伴公开自己报价引擎并将其他合作伙伴服务(如配送集成到该报价应用中来扩展该应用您将如何构造自己业务应用以提供和享受服务?此问题解决方案的是通过将其他和服务相关职责添加到每层中来扩展Three-Layered Application在业