概要

本文对J2EE企业架构应用的基本模式（Core J2EE Patterns）做一个概要介绍。

下图基本上列出了J2EE企业架构应用的基本模式，这些基本模式大致分为以下3类：表示层；逻辑处理层；集成层。

Presentation Tier
Intercepting Filter：
Context Object
Front Controller
Application Controller
View Helper
Composite View
Dispatcher View
Service To Worker

Business Tier
Business Delegate
Service Locator
Session Facade
Application Service
Business Object
Composite Entity
Transfer Object
T O Assembler
Value List Handler

Integration Tier
Data Access Object
Service Activator
Domain Store
Web Service Broker

图：（出自[sun.com]Core J2EE Patterns: Patterns index page）

Data Access Object（数据存取对象）

Data Access Object模式又称数据存取对象模式，它提倡使用Data Access Object（DAO）来抽象与封装所有对数据源的访问。

Data Access Object模式介绍

我们从问题，解决方法，策略，优点等几个方面介绍Data Access Object模式。最后给出Data Access Object的相关联结。

问题

许多J2EE应用都需要在各种不同的地方存取持久数据。这些持久数据可以有各种各样的实现机制，它可以是关系数据库（RDBMS），OODB，文件系统，XML，或者是其他系统诸如LDAP等。对这些持久数据的访问没有统一的规格，需要存取持久数据的组件可能分散在系统的不同地方，它们可能是Session Bean，Entity Bean，或JSP的View Helper，或其它的Java Object等。如果在这些组件中，分散着对持久数据的相同或不同的访问逻辑代码，将存在以下问题：

- 各组件严重耦合数据持久策略。当数据持久策略发生改变时，各组件将变得不可用或不得不进行大面积的修改，也就是说，大大降低了数据持久策略的可变换性。

- 对多种数据持久策略的支持将变得不可能或极其困难。

- 各组件里存在大量重复拷贝风格的代码。

- 对持久数据的存取缺乏统一的存取界面，一方面对持久数据的存取变得困难；另一方面容易造成对持久数据访问API的误用。

解决方法

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

使用Data Access Object（DAO）来抽象与封装所有对数据源的访问。DAO负责管理对数据源的连接，以及数据的存取。

Data Access Object模式结构图：

Client（Business Object）

Client可以是Session Bean，Entity Bean，或JSP的View Helper，或其它的Java Object等..

DataAccessObject

抽象与封装所有对数据源的访问。DAO允许Business Object可以透明地访问数据源。

DataSource

数据源。它可以是关系数据库（RDBMS），OODB，文件系统，XML，或者是其他系统诸如LDAP等。

Data（Transfer Object）

存取的数据。

策略

Data Access Object的生成策略多种多样，可以使用工具自动生成；可以使用虚拟工厂（Abstract Factory）或工厂方法（Factory Method）模式；可以在DAO中进行缓存或者控制只读属性等。

优点：

使用Data Access Object模式有以下好处：

- DAO提供访问数据源的简单界面，容易使用，各Business Object组件可以透明地访问数据源而无需知道其实现细节。

- 容易集成不同的数据源实现方案。

- 减少Business Object组件的代码复杂性。

- 对数据源访问的集中控制。

Data Access Object例：

DAO开发一例：使用Java Generics简化数据库存取类DAO开发

相关模式

Transfer Object

DAO 使用 Transfer Object 来传输数据。

Factory Method [GoF] 与 Abstract Factory [GoF]

DAO 可以使用Factory Method [GoF] 与 Abstract Factory [GoF]模式来实现。

Broker [POSA1]

DAO 担当这样一种角色，它可以打破 资源层与Business Object组件之间的耦合关系。

参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - Data Access Object

DAO开发一例：使用Java Generics简化数据库存取类DAO开发

Session Facade（Session外观）

Session Facade模式又称Session外观模式，它建议在多层分布式的应用中，在逻辑业务处理层增加一种起着外观（facade）作用会话Bean，表示层组件通过该会话Bean与其它业务逻辑处理组件（SessionBean，EntityBean，DAO等）交互。

Session Facade模式介绍

我们从问题，解决方法，策略，优点等几个方面介绍Session Facade模式。最后给出Session Facade的相关联结。

问题

在分布式的多层应用J2EE环境中，往往存在多个小粒度的业务逻辑处理组件（包括SessionBean，EntityBean，DAO等），为了完成某个业务处理，表示层组件（客户端）往往需要调用多个业务逻辑处理组件。表示层对业务逻辑处理组件的大量分散调用，将产生以下问题：

- 表示层与业务逻辑层之间的高度耦合性。表示层严重依赖业务逻辑组件。

- 当表示层组件与业务逻辑处理组件分别位于不同的网络环境中时，对业务逻辑处理组件的大量访问或调用将引起过多的网络访问，影响系统的执行效率。

- 缺乏统一的访问策略，导致业务逻辑处理组件的误用。

题外话：表示层与业务逻辑层之间的高度耦合性问题可以使用Business Delegate模式解消。

解决方法

Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.

使用Facade Session Bean，该Session Bean从更大粒度的业务角度来封装复杂的业务流程，为客户端提供一个更简单的访问界面。

Session Facade模式结构图：

Client

Client可以是一般的Java Object，或者是Business Delegate或其它的SessionBean等。

Session Façade

SessionFacade是一个SessionBean，它负责管理多个BusinessObject，为客户端提供更高级别的访问界面。Client通过SessionFacade完成业务逻辑处理。
Business Object

业务逻辑处理组件。

策略

Session Façade是业务逻辑处理层的控制器，它有以下实现策略：

Stateless Session Facade Strategy

使用无状态会话Bean实现Session Façade。

Stateful Session Facade Strategy

使用有状态会话Bean实现Session Façade。

优点：

使用Session Facade模式有以下好处：

- 担当业务层的控制器角色。

- 为客户端提供统一简单的接口界面

- 减少耦合性，提高可管理能力

- 减少网络调用，提供性能

- 安全管理，事务管理等的集中控制

- 暴露更少的接口给客户端

Session Facade例：

- Session Bean的实现方法请参考相关资料

- Façade形式的实现请参考文末的联结：Façade[GoF]

相关模式

Facade [GoF]

Facade设计模式是Session Facade的基础。

Data Access Object

Session Facade可以使用DAO代替EntityBean进行数据库操作。

Service Locator模式

 Session Facade可以使用Service Locator模式来查找/访问业务逻辑组件。

Business Delegate

表示层组件可以通过Business Delegate访问Session Facade，完成业务处理。

Broker [POSA1]

Session Facade担当打破EntityBean组件与其它客户端之间的耦合性关系这样一种角色。

参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - Session Facade

Business Delegate（业务代理）

Business Delegate模式又称业务代理模式，它建议在多层分布式的应用中，在表示层和逻辑业务处理层之间增加一个代理层，通过该代理层，隐藏业务处理层的实现细节以及实现对业务逻辑的透明调用。

Business Delegate模式介绍

我们从问题，解决方法，策略，优点等几个方面介绍Business Delegate模式。最后给出Business Delegate的相关联结。

问题

在分布式的多层应用系统中，需要进行远程方法调用以及跨层数据接收。表示层组件如果直接与远程业务逻辑处理组件交互，将存在以下问题：

- 业务逻辑处理层的实现细节将暴露给表示层组件，这样，一旦业务层的实现方法发生改变，表示层组件的代码也不得不跟着改变。比如业务逻辑的实现由EJB2.0改由EJB3.0实现的时候。

- 当表示层组件与业务逻辑处理组件分别位于不同的网络环境中时，直接访问或调用将引起过多的网络访问，影响系统的执行效率。

- 服务逻辑处理层的API的开放将导致表示层组件紧密依靠特定的技术实现比如EJB。

解决方法

Use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.

使用Business Delegate（业务代理）来减少表示层与业务逻辑层之间的耦合性，通过Business Delegate隐藏业务逻辑层的实现细节比如lookup以及对EJB的访问细节等,或者其他处理比如对数据或操作的缓存等。

Business Delegate模式结构图：

Client通过BusinessDelegate访问BusinessService，BusinessDelegate可以使用LookupService等查找或创建BusinessService。

策略

Business Delegate模式有多种实现策略：

Delegate Proxy Strategy

Delegate Business通过Proxy模式实现。参考文末联结。

Delegate Adapter Strategy

Delegate Business通过Adapter模式实现。参考文末联结。

优点：

使用Business Delegate模式有以下好处：

- 减少表示层与业务逻辑层之间的耦合性。Delegate Business隐藏了业务逻辑层的实现细节，表示层可以通过Delegate Business透明地访问业务逻辑层组件。

- 集中控制管理能力。表示层对业务逻辑层的访问集中在Delegate Business里进行，一旦业务逻辑发生变化，只需集中修改Delegate Business即可，不会影响表示层代码。

- 错误接管与转换能力。Delegate Business可以catch来自业务逻辑层的网络异常等，并将其转换为表示层易理解的business异常。

- 因为Delegate Business的集中管理，可以在Delegate Business里做一些诸如缓存，线程同步等共通处理。

- 隐藏远程调用远层实现等细节。

- 具有对表示层更友好的接口。Delegate Business可以根据需要，提供给表示层更友好的接口。

Business Delegate例：

下面举例说明Business Delegate。当然，这个例子只列出了大致的框架，并不能真正地运行。

比如，我们要调用的业务层逻辑具有以下接口形式：

它采用EJB2.0实现（实现代码略）。

如果在表示层的组件里（JSP，SERVLET，或View Helper等）直接调用OrderBook EJB组件，则需要在各客户端代码里分别写对该EJB组件的lookup代码，这样不但暴露了OrderBook的实现细节，也使得表示层中的各个组件严重依赖EJB2.0技术。这样的代码产生的问题上面已经作了详细描述。

使用Business Delegate模式，其实现方法一例：

init()方法调用了ServiceLocator来创建/查找OrderBook。这里没给出具体的实现代码。

OrderBookDelegate实现了IOrderBook接口，客户端对它的调用可以通过下面的方法：

IOrderBook orderBook = new OrderBookDelegate();

orderBook.order("mybook");

利用这种方法，可以完全除去表示层对业务逻辑层（EJB技术等）的依赖，不管业务逻辑层使用EJB2.0，亦或是EJB3.0，Hibernate，JDO，JDBC等，表示层可以完全不受影响。

相关模式

Service Locator模式

Business Delegate可以使用Service Locator模式来查找/访问业务逻辑组件。

Proxy [GoF]

GoF代理模式，可以通过Proxy模式来实现Delegate Business。

Adapter [GoF]

GoF适配器模式，可以通过Adapter模式来实现Delegate Business。

Broker [POSA1]

Business Delegate担当打破业务逻辑层组件与其它层客户端组件的耦合性关系这样一种角色。

参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - Business Delegate