模式与框架

模式与框架Java EE设计与开发

目录

第1章模式与框架介绍 (3)

1.1 什么是模式 (3)

1.2 什么是框架 (3)

1.3 模式与框架的区别 (3)

1.4 架构模式 (4)

1.5 Java EE核心模式 (4)

1.6 GOF模式 (7)

第2章数据层框架与模式 (8)

2.1 示例 (8)

2.2 使用模式 (10)

2.3 使用设计原则 (17)

2.4 数据层框架 (22)

2.5 调用 (30)

第3章业务层框架与模式 (77)

第4章表现层框架与模式 (79)

第5章 MVC框架与应用 (79)

第1章模式与框架介绍

1.1 什么是模式

模式就是解决问题的方法论。每一种模式都描述了解决某一类问题的最佳方法，至少到目前为止是。模式是理论与实践相结合而总结出来的最有效的解决方案，它将随着技术的发展而不断创新，不断完善，所以旧的模式会发现不再适用，而新的模式会出现。

模式在各个应用领域都有，譬如在建筑设计中，模式最为常见。如将门安装在距离墙角落120公分处，窗户与栏杆的高度在90公分左右，长高宽为300的模数等。同理，软件设计中，模式也是层出不穷，大量的架构模式，创建模式，结构模式，行为模式，表现层模式，业务层模式，数据层模式等等。

1.2 什么是框架

就是一组组件、类或接口构成的半成品，仅完成了某些基本功能，譬如日志，安全性，数据访问等，但需要在此基础上进行业务开发，最终构成一个可用的业务系统。基于框架的开发可以节省大量的精力而致力于系统的业务逻辑设计。

譬如在建筑领域，屋架、梁柱就是一个典型的框架，是一个半成品。屋架的作用是承重，但不能遮风挡雨，必须在上面盖瓦或铺设覆盖物，形成屋顶，才能具备完整的功能；粮柱的其本作用是划分空间、承受垂直与横向的压力，但不具备封闭空间、隔声的效果，尚待在柱间砌筑墙体，在梁间铺设楼板才能居住。

在软件开发中，框架仅提供了部分通用的功能，还必须经过业务的填充，才能形成一个功能齐全的业务系统。

1.3 模式与框架的区别

从规模上讲，模式专注于微观层面的分析与设计，而框架着眼于宏观的构造。

从实现的角度看，模式只是一种解决问题的方法，一个解决方案，而框架却是一个实

现这种方案的具体的产品，有着实际的功效与作用。

从关系上讲，模式是框架的理论基础，多个模式的实现构成了一个框架。框架是模式的具体实现，一个局部或全局的框架，一般都要用到模式。

既然是框架，本身就表示它是一种好的通用的产品，怎么体现它是好的呢，模式恰好证明了它是解决某一类问题的最好的解决方案，所以说，没有用到模式的框架，将不是一个良好的可用的框架。

1.4 架构模式

专注于体系结构宏观的组成与创建，而不注重其细节。譬如建筑设计中常用的体系结构模式有：低层建筑采用砖混结构，中高层采用梁柱框架结构，高层建筑普遍采用钢结构、剪力墙结构、洐架结构。

在软件应用领域，架构模式也是丰富多用，主要有以下几种：

层次模式：Layers

管道和过滤模式：Pipes and Filters

代理模式: Broker

黑板模式：Blackboard

水平-垂直元素模式：Horizontal-Vertical Metadata

MVC模式：主要针对系统或子系统和接口

1.5 Java EE核心模式

在java web应用与企业应用领域，常用的体系架构是MVC。而MVC正好体现了分层的思想。各层之间的联系与区别如下图：

我们一般将视图（View）与控制器（Controller）叫做表示层，而模型层太笼统，在实际中，我们将模型层分割为业务层与数据层。其中v或

v+m构成了我们的model1架构，v+c+m构成了model2架构，又叫web MVC

或mvc2架构，因为不支持推式。但我们习惯将其称为MVC体系架构。

Sun java Center

定义了15种设计模式，在《Core J2ee Patterns》书中发表。按照MVC 的分层，在每一层都提出了几种模式，这些模式分别组成各层，最后组成一个完整的MVC框架。

这些模式分为：

➢表现层模式，又称Web层模式，用于Web层的界面与servlet开发；

➢业务层模式，又称应用层模式，用于业务逻辑的分层与调用；

➢数据层模式，又称集成层模式，用于数据访问

表现层模式

Intercepting Filter(截获过滤)

对请求和响应进行截获和过滤，在Servlet2.3中已实现的Filter功能就是属于此模式。该模式可用于单点登陆，以及登陆过程验证等等。

Front Controller(前端控制器)

Servlet设计的思想主要是用来调度和转发。即调用模型层的类来处理请求，然后将处理后的信息转发到响应页面进行展示，绝不能将业务逻辑代码堆砌在servlet方法中。那么如何能体现servlet的这一功能需求呢，前端控制器模式很好的解决了这个问题，在一

个项目中，只有一个控制器，它是系统的一个入口，由他调用相应的逻辑Bean，完成相应的处理工作后，更新视图View。

View Helper(视图帮助器)

将表现层和表现层的数据进行分离，将表现层的数据单独封装一层，从而可以更加轻松的在表现层进行处理与传递，而与表现层各层低耦合，这就是View Helper模式。

Composite View(复合视图)

页面层内容繁多，如何更有效的组织与重用？复合视图模式将一个复杂的页面拆成多个可重用的页面，各页面在程序调用过程中分别维护和显示，从而减少了前台页面的复杂性，也更容易进行个性化和定制。

Dispatcher View(派遣视图)

类似于Service to Worker模式，由Front Controller和View Helper模式组合而成。Front Controller接受请求，不进行任何业务逻辑处理，立即重定向到请求的服务页面，由页调用模型层代码进行处理。这个模式在视图中进行请求处理，缺点是不适合大型的复杂的应用程序开发，优点是页面快速响应。

Service to Worker（服务/工人）

与Dispatcher View模式共同的地方是，也是由Front Controller和View Helper模式组合而成，不同的是，Front Controller接受请求以后，首先进行任何业务逻辑处理，根据处理结果的不同，而定位到相应的响应视图，适合用于大型的复杂业务逻辑的应用系统。

业务层模式

Business Delegate（业务代理）

如何减少表现层与数据层的耦合问题，业务代理模式将业务逻辑做了封装，同时也将数据层的接口做了进一步抽象，从而缓存了调用逻辑，减少了调用开销。

Value Object（值对象）

如何解决表现层与业务层之间的数据交换，以及层内部的数据交换问题呢？将常用的数据单独封装成一个javaBean，这样便于传递，也便于取值与设置值。与Map接口不同的是，VO更方便对值进行操作。

Value Object Assembler（值对象汇编器）

将不同的值对象组装成一个更大的值对象，方便在表现层与数据层之间传递数据。

Session Façade

该模式提供了下一层接口的一个抽象视图，而不是简单地把下一层的 ApI 直接包装起来。常用在对实体Bean的访问中，以及需要开发分布式业务时装封业务逻辑。

Composite Entity（复合实体）

用于EJB1.1中封装实体Bean，已过时。