一. 设计模式重要性架构的设计好坏将直接影响系统的性能、可扩展性、可维护性、组件可重用性及开发效率。项目越复杂,项目队伍越庞大则越能体现良好设计的重要性。 二. 常见EJB设计模式
Session Facade Pattern
图1:客户端直接与实体EJB交互
图2:通过SessionEJB层实现数据库操作;SessionEjb内某些系统通用操作的代码容易重复(比如权限检查等,解决办法是将系统通用服务封装在Java Class内)。
Message Facade Pattern
图3:使用Message Facade Pattern
Message Facade Pattern的不足之处在于:
EJB Command Pattern
Session Facade Pattern中将商业逻辑实现封装在Session EJB中,这种做法带来诸多益处之外也带来如下问题:
整个框架见下图4:
图4:Command的基本框架Data Transfer Object Factory
图6:DTO Factory示例
图7:SessionEJB实现DTOFactory
Generic Attribute Access
使用Entity EJB作为商业数据层时,我们首先需要从数据库加载数据,创建对应的Entity EJB实例,之后对内存中Entity EJB实例的属性进行相应操作。对属性的操作比较直接的做法是:直接调用Entity EJB的getXXX()/setXXX(),通常利用EJB2.0的本地接口;通过DTO Factory生成DTO。但这两种做法都存在如下问题:
图8:Generic Attribute Access Interface示例
Generic Attribute Access Interface由Entity EJB的本地或远程接口实现,并利用Hash Maps传输数据。实现方式常见如下:Business Interface
EJB规范要求Bean实现类必须实现所有在远程(或本地)接口中定义的所有方法,同时不允许Bean实现类直接继承远程(或本地)接口。这就导致编译时候很容易产生两者不一致的问题,即远程(或本地)接口中定义的某方法为在Bean实现类中被实现等错误。为避免上诉错误,可以利用应用服务器厂商所提供的工具。但也可以应用EJB的设计架构来实现:定义商业接口。
图9:商业接口的使用
三. 内部数据转换策略
Data Transfer Object
图10:低效的数据传递方式 图11:通过DTO传递数据
图12:Account EJB 与 Account DomainDTO
Custom DTO则可以克服上述的一些缺点。Customer DTO仅仅封装用户感兴趣的服务器数据集即可以根据客户端需求创建Customer DTO。这样作的优点是灵活高效;缺点是大项目中可能导致大量的Customer DTO存在。
Domain Transfer Hash Map
Data Transfer RowSet
图13:使用RowSet
四.事务和数据持久机制
JDBC for Reading Pattern
基于EJB的J2EE应用中,通过EJB对数据库的操作可以有两种方式:实体EJB或者Session EJB中直接利用JDBC访问。
出处:http://blog.csdn.net/guolong1983811/article/details/51195300