南京理工大学-设计模式在分层架构中的应用分析-作业模板

1、软件结构设计与模式分析论文 论文题目：设计模式在企业管理分层架构中的应用 学 号： XX 姓 名： XX 联系方式： XX 设计模式在企业管理分层架构中的应用摘要：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。设计模式是一种抽象思想，它在对象的创建、组成以及行为等方面提供了一套精练的解决方案。分层架构将某一应用系统划分成多个子任务组，每个

2、子任务组处于一个特定的抽象层次中。分析了传统分层架构存在的缺陷后，提出了将设计模式应用到分层架构中，解决了层与层之间以及各层内部对象之间的高耦合问题，从而使架构更加灵活，方便了系统的扩充和维护。1.引言 层既是一种软件体系结构风格，也是一种软件体系结构模式，它有助于将应用系统分成子任务组，其中每个子任务组处于一个特定的抽象层次中。但是简单的层次划分并没有解决对象之间的高耦合问题。将设计模式引入到分层架构中能够使得各层的内部组成之间以及层与层之间的耦合度大大降低，扩展性大大提高，这样既有利于将复杂问题分而治之，也有利于每一层更加灵活的进行重用。分层体系架构使整个系统各部件分离，解除了“一变全动”

3、的困扰。2.系统架构与设计模式 如果说设计模式是微观方面的内容，那么架构就可以说是宏观方面的内容。架构描述了软件体系基本的结构化组织方案，提供了一套预先定义好的子系统来定制它们的职责，包括用于它们之间的规则和指南。架构的物理实现往往表现为一套详细而准确的类以及相关的配置文件，类与类之间功能各异，彼此调用，相互协作形成了对某一类重现问题的可重用、可扩展的解决方案。通常情况下架构是要针对特定平台的，例如 MVC 在 SmallTalk 中的实现是一个架构，EJB是J2EE 下的一个架构，254JavaBean 也是 Java 平台下的架构。 在实际基于某种架构的应用中通常所做的工作是扩展该架构中的

4、子类以及组织架构中类的实例。经过大量的面向对象的企业系统开发之后，就会发现不同的系统中会有大量相似结构的出现。通常情况下这种相似结构的解决方案也是相似的，而描述这种确定领域的相似需求和相似解决方案的工具便是设计模式。设计模式是系统设计师软件开发经验的总结，设计模式相对于架构更加抽象，架构在不同的平台下可能呈现出不同的表现形式，有时貌似不同的架构可能完全出于同一种设计模式。一个架构可以看作是由多个设计模式组合成的解决方案的物理实现，设计模式指导如何实现这个方案。3.设计模式对分层架构的优化设计典型的企业分层系统架构是将系统分为三层，即表示层、业务层、数据层。每层完成不同的工作，但它们之间又不是相

5、互独立的，而需要彼此通信，相互协作完成整个架构的功能。数据层向业务层提供底层数据的访问处理功能；业务层向表示层提供业务流程控制和数据模型封装功能，避免了表示层直接访问数据层，使得表示与数据处理的完全分离。传统的三层结构的框架图如图 1 所示：图1 典型的三层结构图 表示层是不能直接与数据层进行通信的，而只能通过业务层与数据层进行通信，在传统的三层架构中已经做到了这一点。但是，从图 1 不难看出传统三层架构存在的缺陷，在实际的企业系统中一项业务可能会涉及到多个数据操作，业务层与数据层的耦合度比较高，这势必要求负责业务层的每个开发人员对数据层的所有接口必须非常熟悉，才能完成各种数据操作。这不仅对业

6、务层的开发人员提出了高要求，而且在每个业务类中会充斥着大量的数据层的类。这样一来数据层中某个部分发生变动可能会牵扯到多个业务层类的改动。为解决这一问题我们引入 Command 模式，在业务层与数据层之间加入命令对象层，如图 2 所示。图2 加入命令对象层之后的模式框架 引入 Command 模式后，虽然实现了业务层与数据层之间的脱耦，但是架构中仍存在缺陷。每个表示层对象都对应着一个业务层对象，因此在系统中可能就存在大量的业务类，而这些业务类中可能有许多功能相似的部分，使得这些相似的功能普遍存在于大量的业务类中。如此设计的缺陷也就暴露出来，相似功能分别由不同人员重复开发，一是造成了资源的浪费，更

7、主要的是给系统的维护和扩充带来极大的不便，如果某一业务功能需要扩充或者变动，那么与此相关的所有业务类都要进行改变。为了使表示层与业务层之间的联系变得松散，我们引入 Façade（门面）模式，在这两层之间加入一个门面对象层，如图 3 所示。图3 加入门对象层之后的模式框架如此一来便对表示层与业务层进行了脱耦，当某个业务发生变化时，要么改变门面中的业务对象的组合要么对业务层中的业务类进行修改，而不需要对调用该业务对象的所有表示层对象进行修改。这也使得系统更容易扩充，当有新业务添加时，我们只要把新的业务注册到门面对象中，表示层就可以对其进行透明访问。4.设计模式在分层架构中的实现上节中给出

8、了利用 Command 模式和 Façade 模式对分层体系架构的优化方案，在这节中将以设备管理系统为背景详细阐述优化之后的系统架构的实现。设备管理系统包括设备的基础信息管理、设备的申请管理、申请的审批管理等等业务，其中设备的申请包括了设备的购置申请、调拨申请、报废申请。图 4 所示的是申请管理的类图。图 4 设备申请管理的类图Command 模式涉及到三个角色，即命令发出者角色、命令角色和命令接收者角色。业务层对象充当命令发出者角色，命令对象充当命令角色，数据层对象充当命令接受者角色。在每个命令对象中都持有命令接收者的引用，命令对象通过调用命令接收者中的具体方法来完成相应的命令。例

9、如，新增一条设备购置申请信息包括合法性验证、添加记录、登记日志三个操作，我们将这三个具体的操作组合成一个命令对象。因此命令对象PurchaseCommand 的命令接收者是 PurchaseDao、LogDao 和 ValidateDao。它向业务层提供的新增购置申请的命令执行接口是 addApply，在接口中会执行命令接收者的具体指令。示例 1 给出了设备购置申请管理的业务类PurchaseApply 和命令类 PurchaseCommand 的主要代码框架。示例 1：public class PurchaseApplyPurchaseCommand command;public void

10、addApply()command.addApply();public class PurchaseCommand ValidateDao dao1;PurchaseDao dao2;LogDao dao3;public void addApply()dao1.validate();/执行命令接收者 1 中的命令dao2.add();dao3.log();/执行命令接收者 2 中的命令 为了向表示层提供统一的访问业务层的接口，上面的设计方案中在表示层与业务层之间加入了一个门面层。表示层对象只要告诉门面所要完成的业务即可，而不必再关心操作具体是如何实现的。门面模式涉及到了三个角色，即访问门面的客

11、户角色、门面角色 、子系统角色。在上面设计方案中充当三个角色的分别是表示层对象、门面对象、业务层对象。门面对象持有所有业务对象的引用，它会根据表示层的不同请求将不同的业务对象进行组合来完成相应的业务。示例 2 给出了门面对象的主要代码框架。示例 2：public class Facadepublic void execute()switch(business)case “purchase”:if(operation.equals(“add”)PurchaseApply.addApply();if(operation.equals(“update”)break;case “exchange”:i

12、f(operation.equals(“add”)ExchangeApply.addApply();if(operation.equals(“update”)break;case “reject”:从门面对象的代码可以看出，当有新的业务添加到系统时所做的工作就是，编写新业务类并在门面对象中进行登记，然后再与相应的其他业务进行组合调用就可以满足需求，而没有对已有的业务类进行大量修改。这样就很轻松的实现了系统的扩充。5.结论虽然分层会增加代码程序的复杂性，但是使得整个系统的构架更加清晰明了，更加易于理解。因为系统被严格地分层，如果某一天某个功能的业务逻辑发生变化，只要更新业务逻辑层就行，不需要惊动其他层，同样道理，如果其他层发生了变化的话，也不会影响其他层，使得系统稳定性增加。系统的分层使得各部分各负其责，避免了“一变全动”，也方便了开发人员的分工，发挥各自的长处。将设计模式贯穿于整个架构中，能使架构的各部分更好地通信、更有效地协调工作。同时设计模式在各层中的应用使得整个架构更容易扩充、更