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

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

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
南京理工大学-设计模式在分层架构中的应用分析-作业模板分析

软件结构设计与模式分析论文 论文题目:设计模式在企业管理分层架构中的应用 学 号: XX 姓 名: XX 联系方式: XX 设计模式在企业管理分层架构中的应用 摘要:设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。设计模式是一种抽象思想,它在对象的创建、组成以及行为等方面提供了一套精练的解决方案。分层架构将某一应用系统划分成多个子任务组,每个子任务组处于一个特定的抽象层次中。分析了传统分层架构存在的缺陷后,提出了将设计模式应用到分层架构中,解决了层与层之间以及各层内部对象之间的高耦合问题,从而使架构更加灵活,方便了系统的扩充 和维护。 1.引言 层既是一种软件体系结构风格,也是一种软件体系结构模式,它有助于将应用系统分成子任务组,其中每个子任务组处于一个特定的抽象层次中。但是简单的层次划分并没有解决对象之间的高耦合问题。将设计模式引入到分层架构中能够使得各层的内部组成之间以及层与层之间的耦合度大大降低,扩展性大大提高,这样既有利于将复杂问题分而治之,也有利于每一层更加灵活的进行重用。分层体系架构使整个系统各部件分离,解除了“一变全动”的困扰。 2.系统架构与设计模式 如果说设计模式是微观方面的内容,那么架构就可以说是宏观方面的内容。架构描述了软件体系基本的结构化组织方案,提供了一套预先定义好的子系统来定制它们的职责,包括用于它们之间的规则和指南。架构的物理实现往往表现为一套详细而准确的类以及相关的配置文件,类与类之间功能各异,彼此调用,相互协作形成了对某一类重现问题的可重用、可扩展的解决方案。通常情况下架构是要针对特定平台的,例如 MVC 在 SmallTalk 中的实现是一个架构,EJB是J2EE 下的一个架构,254JavaBean 也是 Java 平台下的架构。 在实际基于某种架构的应用中通常所做的工作是扩展该架构中的子类以及组织架构中类的实例。经过大量的面向对象的企业系统开发之后,就会发现不同的系统中会有大量相似结构的出现。通常情况下这种相似结构的解决方案也是相似的,而描述这种确定领域的相似需求和相似解决方案的工具便是设计模式。设计模式是系统设计师软件开发经验的总结,设计模式相对于架构更加抽象,架构在不同的平台下可能呈现出不同的表现形式,有时貌似不同的架构可能完全出于同一种设计模式。一个架构可以看作是由多个设计模式组合成的解决方案的物理实现,设计模式指导如何实现这个方案。 3.设计模式对分层架构的优化设计 典型的企业分层系统架构是将系统分为三层,即表示层、业务层、数据层。每层完成不同的工作,但它们之间又不是相互独立的,而需要彼此通信,相互协作完成整个架构的功能。数据层向业务层提供底层数据的访问处理功能;业务层向表示层提供业务流程控制和数据模型封装功能,避免了表示层直接访问数据层,使得表示与数据处理的完全分离。传统的三层结构的框架图如图 1 所示: 图1 典型的三层结构图 表示层是不能直接与数据层进行通信的,而只能通过业务层与数据层进行通信,在传统的三层架构中已经做到了这一点。但是,从图 1 不难看出传统三层架构存在的缺陷,在实际的企业系统中一项业务可能会涉及到多个数据操作,业务层与数据层的耦合度比较高,这势必要求负责业务层的每个开发人员对数据层的所有接口必须非常熟悉,才能完成各种数据操作。这不仅对业务层的开发人员提出了高要求,而且在每个业务类中会充斥着大量的数据层的类。这样一来数据层中某个部分发生变动可能会牵扯到多个业务层类的改动。为解决这一问题我们引入 Command 模式,在业务层与数据层之间加入命令对象层,如图 2 所示。 图2 加入命令对象层之后的模式框架 引入 Command 模式后,虽然实现了业务层与数据层之间的脱耦,但是架构中仍存在缺陷。每个表示层对象都对应着一个业务层对象,因此在系统中可能就存在大量的业务类,而这些业务类中可能有许多功能相似的部分,使得这些相似的功能普遍存在于大量的业务类中。如此设计的缺陷也就暴露出来,相似功能分别由不同人员重复开发,一是造成了资源的浪费,更主要的是给系统的维护和扩充带来极大的不便,如果某一业务功能需要扩充或者变动,那么与此相关的所有业务类都要进行改变。为了使

文档评论(0)

10577 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档