Java EE 设计模式学习笔记——不佳实践

所谓不佳实践，也就是与模式推荐的思路冲突一些不太理想的解决方案。

 

表现层不佳实践

1.   多个视图中都包含控制代码；

解决方案：引入控制器；隔离不同逻辑；命令与控制策略。

2. 把表现层的数据结构暴露给业务层

3. 把表现层的数据结构暴露给业务领域对象

4. 允许重复提交表单

解决方案：引入同步器令牌；控制客户端访问

5. 把敏感资源暴露给客户端的直接访问

解决方案：对客户端隐藏资源；控制客户端访问

6. 假定<jsp:setProperty>会重置bean属性

7. 创建出“胖控制器”

解决方案：引入控制器；命令与控制器策略；隔离不同逻辑；视图助手

8. 把视图助手当成scriplet使用

 

业务层和集成层不佳实践

1. 把对象模型直接映射为entity bean模型

entity bean粒度太细，容器和网络负担很重，引起严重性能问题

解决方案：减少entity bean之间的通信；复合实体模式；把相关的工作流合并到session bean中；会话门面模式

2. 把关系型模型直接映射为entity bean模型

问题和解决方案同上

3. 把每个用例映射为一个session bean

产生大量的session bean，从而显著增加了应用的复杂度。

解决方案：合并session bean; 会话门面模式

4. 通过Getter/Setter方法暴露EJB的所有属性

迫使客户端进行许许多多细粒度的远程调用，从而可能在各系统层次之间产生大量的网络传输，影响系统的性能和可扩展性。

解决方案：使用值对象来在客户端和服务器端传递聚合数据-〉传输对象模式

5. 在客户端中包括服务寻址代码

解决方案：服务定位器来封装寻址机制的实现细节；业务代表封装业务层组件的实现细节---客户端不需要跟EJB和服务直接打交道。

6. 把entity bean当成只读对象使用

解决方案：使用session bean实现只读访问功能，通常这被实现为一个利用了DAO的会话门面；为了获取一组传输对象，可以实现值列表处理器模式；为了从业务层获取复杂数据模型，可以实现传输对象模式

7. 把entity bean当成细粒度对象使用

解决方案：复合实体；会话门面；减少entity bean之间的通信；将业务逻辑移至session bean；合并session bean；entity bean包含的业务逻辑应该是自足的，只处理它本身的数据和它的从属对象的数据。

8. 存储entity bean的整个从属对象拓扑结构

解决方案：复合实体模式及存储优化策略；懒装载策略

9. 把EJB相关的异常暴露给非EJB客户端

解决方案：引入业务代表

10. 使用entity bean finder方法返回大型结果集

解决方案：利用session bean和DAO来实现查询，获取一组传输对象，而不是远程引用。

11. 客户端负责聚合来自业务组件的数据

解决方案：传输对象组装器

12. 把EJB用于长时间持续的事务

解决方案：使用支持JMS API的消息中间件(message-oriented middleware, MOM)实现异步处理服务，用以实现长时间持续的事务。

13. 每次调用无状态session bean都要重建对话状态

解决方案：有时候需要在多个方法调用之间维护对话状态就是用有状态session bean。