j2ee项目实训uml及设计模式——第7章架构设计中的架构模式第1部分

j2ee项目实训uml及设计模式——第7章架构设计中的架构模式第1部分内容摘要：

系统的设计人员将复杂的系统中所涉及的各个方面的问题分解成一个 层次 的实现。 由于在分层后的系统结构中，每一层最多只影响其相关联的上、下两层， 同时只要给相邻的上、下层提供接口或者实现接口，从而也就能够允许每层使用不同的方法包括不同的技术来实现，因此为软件的重用提供了强大的结构支持。 将系统进行合理地分层的另一个好处是，这些层形成了应用系统开发小组的自然分界—— 因为对每层的开发人员所需要的技巧是不同的 、项目分工时可以根据人员的技术水平和对相关的层所涉及的技术熟练程度进行合理地任务分配。 比如，用户界面层的开发小组人员需要了解将使用的用户界面工具和实现的相关的技术等；持久层的开发小组人员需要熟悉相关的数据库、持久工具等。 层架构模式在 J2EE 平台 系统开发中的应用 （ 1）标准的三层架构的系统 J2EE 平台能提供多层分布式应用模型并能重用组件（这主要是由 EJB 组件技术来实现），同时也为用户提供统一的安全模型（声明式和编程式的具体实现）和灵活的事务处理（声明式事务和编程式的事务具体实现）控制。 Martin Fowler 在《 Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层 （ Presentation） 、领域层（ Domain）和数据源层 （ Data Persistence）。 （ 2） J2EE 平台系统开发中常见的分层策略 但是在实际的项目开发中， 应用系统的设计人员 通常 会 对 标准的 三层 架 构进行扩展 以满足 应用系统中 的具体要求。 一个最常 见 的扩展 方式 就是将三层体系 架构 扩展为五层体系架构 ，即 将整个应用系统分离为 表示层 （ Presentation）、 控制层 （ Controller） 、 业务逻辑层 （ Business Logic） 、 数据持久层 （ Data Persistence） 和数据 存储 层 （ Data Source）。 杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权 所有，盗版必究 ， 8/17 页 J2EE 平台系统开发中这样的分层策略， 其实是在 标准的 三层架构中增加了两个中间层—— 控制层位于表示层和 业务逻辑 层之间 、 数据持久层位于 业务逻辑 层和基础 的 数据 存储层之间。 从 上面的分层 设计 结果来看应用系统的架构时 ：由于 系统中的各个部分被分离为不同的部分，并且在具体的 实现 方面各个 层次 中的组件是 完全分离 的 ， 这样将能够使 业务 处理逻辑 功能成为 应用系统的 中间功能 服务 （ 也就是 中间层）。 中间 业务 层 的具体实现时 ， 可以 不依赖 系统中 具体的表示层技术，也不依赖 于系统中 具体 的 数据 层的 技术 实现。 多层架构倡导的显示功能、业务 逻辑处理 功能和数据 访问 功能完全分离，从而避免了在应用系统的需求发生变化时（功能方面或者非功能方 面），而产生 牵一发而动全身的连锁 修改系统的设计方案和实现的代码 ，可以实现 系统的 松耦合和良好的 系统 可维护性。 对层架构模式的优缺点分析 （ 1）使用层架构模式的 主要 优点 在构造应用系统时，架构设计师可以把整个系统想象成是由不同的“积木”块 （在软件系统中的 积木块 ，也就是各个功能组件） 而构成的， 这些 “积木”块 之间的关系一般体现为 纵向 的分层和 横向 的功能模块组件。 系统的开发人员可以向系统中插入所需要的某个“积木”块以扩充其功能 、或者替换掉其中的某个 “积木”块 而完善系统的功能。 在这种分层体系的结构中，应用系统都被 表示为由一系列相关联的各层单独的子系统所构成，而每个层中的子系统又都采用组件技术来设计和构造，每个组件系统也可以对其上、下层中的组件进行调用。 这种体系结构，最后将能够达到层的上层使用者只管使用所需要的目标层，而并不需要去了解该目标层的具体结构以及该目标层中的各个组件的具体技术实现细节；同时当应用 系统 的需求发生变化时，只需要改变某些基础层，但不会影响到其上层的应用实现。 这主要是由于各个层之间是相互隔离的。 在应用 层架构模式时，设计人员应该 制定出各层的接口标准， 层与层之间进行关联时只通过接口进行连接， 从而可以 减少不同层之间的相互依赖。 将系统划分成多层结构的最大好处是提高了开发速度、增强系统的健壮性和稳定性、提高了系统的可维护性和拓展性，也能够 大大节约系统开发成功后的维护 、完善 修改 的 成本。 （ 2）使用层架构模式的 主要 缺点 杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权 所有，盗版必究 ， 9/17 页 使用层架构模式 不可能封装所有的功能，一旦有功能变动，势必要波及到各个关联的层（一般为其上、下两层）。 为了尽可能地减少这样的影响，设计人员一定要 通过接口进行连接 ；另外在数据传送方面将会体现出低效，比如在 J2EE 的多层架构的系统中，如果要实现在数据访问层中将某个数据对象传送到表示层，将要“穿透”相关 的许多层。 层模式的应用及系统分层设计策略 非分层架构设计时对应用系统所可能带来的问题 （ 1）整个系统是一个高度藕合的系统 由于系统中的许多部分高度地耦合和相互关联，因此应用系统中某个功能模块的需求一旦发生变化时，将会波及到整个系统中的各个关联的不同部分都会被动地进行修改。 （ 2）降低了系统的可重用性 由于整个应用系统中的各个功能模块是相互组合在一起的，特别是系统中的核心应用逻辑的功能具体实现与用户访问接口的表示层的具体实现技术捆绑在一起。 当然这些应用逻辑在其它不同的表示层的接口上将无法被重用，导致“ 拔出萝卜带出泥”的结果。 另外还由于潜在的通用技术服务（如数据库访问的事务、系统的安全验证、对象缓存、日志记录等）或业务逻辑，与更具体的应用逻辑捆绑在一起，因此这些通用的技术服务或者业务逻辑功能的实现也将面临着无法被重用。 （ 3）不便于系统的模块划分和人员分工 由于系统的不同功能模块是高度地关联和耦合，因此难以对应用系统中不同的开发者清晰界定各个模块的工作界限、功能实现的要求和人员分工；同时由于高度耦合的系统中一定会混合了系统的各个方面的功能模块，因此在改进应用系统的具体功能的实现时，特别是在扩展系统功能以 及希望能够应用新技术时将会付出更大的代价。 如何解决上面所提及的各个问题 对上面所提及的“非分层架构设计时对应用系统所可能带来的问题”解决的具体方案是采用层架构模式，并且基于下面的 分层设计策略实现。 当然，在层 模式的系统架构 设计工作中最难的一个问题，还是一个具体的应用系统到底 应该分为几层 、每个层中都 应该提供那些功能组件 ，以及每个组件中的各个类 要承担什么方面的职责等方面的问题的解决。 杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权 所有，盗版必究 ， 10/17 页 （ 1）系统分层时应该遵守“高内聚、低藕合”的职责设计原则 一般，可以把应用系统中的“粗粒度的逻辑结构”组。