EJB 设计模式概述

一． 设计模式重要性架构的设计好坏将直接影响系统的性能、可扩展性、可维护性、组件可重用性及开发效率。项目越复杂，项目队伍越庞大则越能体现良好设计的重要性。 二． 常见EJB设计模式

Session Facade Pattern 

图１：客户端直接与实体ＥＪＢ交互 图２：通过SessionEJB层实现数据库操作；SessionEjb内某些系统通用操作的代码容易重复（比如权限检查等，解决办法是将系统通用服务封装在Java Class内）。

Message Facade Pattern

　图３：使用Message Facade Pattern

Message Facade Pattern的不足之处在于：

EJB Command Pattern

Session Facade Pattern中将商业逻辑实现封装在Session EJB中，这种做法带来诸多益处之外也带来如下问题：

　整个框架见下图４：

图４：Command的基本框架Data Transfer Object Factory

图６：DTO Factory示例 图７：SessionEJB实现DTOFactory

Generic Attribute Access

使用Entity EJB作为商业数据层时，我们首先需要从数据库加载数据，创建对应的Entity EJB实例，之后对内存中Entity EJB实例的属性进行相应操作。对属性的操作比较直接的做法是：直接调用Entity EJB的getXXX()/setXXX()，通常利用EJB2.0的本地接口；通过DTO Factory生成DTO。但这两种做法都存在如下问题：

图８：Generic Attribute Access Interface示例

Generic Attribute Access Interface由Entity EJB的本地或远程接口实现，并利用Hash Maps传输数据。实现方式常见如下：Business Interface

EJB规范要求Bean实现类必须实现所有在远程（或本地）接口中定义的所有方法，同时不允许Bean实现类直接继承远程（或本地）接口。这就导致编译时候很容易产生两者不一致的问题，即远程（或本地）接口中定义的某方法为在Bean实现类中被实现等错误。为避免上诉错误，可以利用应用服务器厂商所提供的工具。但也可以应用EJB的设计架构来实现：定义商业接口。

图９：商业接口的使用

　三． 内部数据转换策略

Data Transfer Object

图１０：低效的数据传递方式 图１１：通过DTO传递数据 　图１２：Account EJB 与　Account DomainDTO

Custom DTO则可以克服上述的一些缺点。Customer DTO仅仅封装用户感兴趣的服务器数据集即可以根据客户端需求创建Customer DTO。这样作的优点是灵活高效；缺点是大项目中可能导致大量的Customer DTO存在。

Domain Transfer Hash Map 

Data Transfer RowSet

图１３：使用RowSet

四．事务和数据持久机制

JDBC for Reading Pattern

基于EJB的J2EE应用中，通过EJB对数据库的操作可以有两种方式：实体EJB或者Session EJB中直接利用JDBC访问。

出处：http://blog.csdn.net/guolong1983811/article/details/51195300