量的好。
　　推荐一个关于 EJB 设计模式的好地方：
　　http://www.theserverside.com/resources/patterns_review.jsp
　　7、分清 Entity bean 和 session bean 的职责
　　Entity bean 是实体的对象形式，它的职责应限于自身的存储，以及对外部提供访
问内部数据的接口(所以我认为它本质上应该属于数据存储层)。Entity bean 应该尽量避
免自己实现有其他 Entity bean 参与的业务逻辑。例如，订单的货款收到以后，将订单的

“

”

“

”

状态由 提交 变为 生效 ，同时将订单的金额按照某种规则折算成该客户的积分。这个业
务流程有三个对象参与：客户，订单和积分折算策略。那么，实现流程的方法应该在哪个
对象中呢，是客户还是订单?都不合适，如果在订单中，那么订单对象需要了解客户积分
属性的接口及积分折算的接口;如果在客户对象中也是一样。耦合度增强就意味着维护难
度增大，如果用户对象的积分接口或者折算策略的接口改变了，那么改变就会蔓延到订
单对象中。合适的方式是用一个 OrderProcessor 来管理订单处理流程，以 stateless 
session bean 来实现。OrderProcessor 了解所有参与订单处理的对象的接口，它集中
管理对订单的处理流程，如果流程发生变化，订单生效之前要通过审批，这种变化不会
影响到参与流程的实体对象;同样，参与流程的某个对象接口发生了变化，也不会影响到
其他对象。
　　8、重视表现层的复用
　　企业软件的界面，大部分都可以用一些基本元素如 grid, tree, page control, form
等组合而来。如果能合理采用一些技术对这些元素进行复用，不但有利于降低开发成本，
而且也便于统一维护界面风格。对 J2EE 的表现层，也就是 JSP/servlet，可以采用的复用
技术不多，基本上就是文件包含、创建类库、Tag lig(本质上还是创建类库，使用起来我觉
得还不一定有直接方法调用来的方便)等等。还有一些不同于 JSP/servlet 的表现层框架，
如 Apache Velocity、Enhydra、WebMacro 等等，也可以参考。虽然 Java 还没有一个规
范的、统一的 HTML 界面元素类库，但自己项目内部统一使用某种方案还是可能的。
　　另外，XML+XSLT 也是一种方案。将数据直接用 XML 形式表现出来，绕过 Entity 
bean，然后再用 XSLT 模版转化成最终界面。XML 与 XSLT 之间属于模式匹配式的松散耦
合，可以避免强类型语言方法调用带来的参数类型、个数、顺序限制，做到彻底地数据与
界面分离;同时 XML 形式的数据集在 app server 中可以按照合适的方案进行缓冲，避免
频繁访问数据库，抵销 XSLT 转换引入的性能负担。同时 XML 和 XSLT 是业界广泛采纳的
标准，如果今后采用不同的体系结构(如从 J2EE 移植到.Net 或者相反)，表现层的 XSLT
形式的界面可以重用。JSP 或 ASP 就没有这种可能。问题在于首先要管理关系型数据到层
次型 XML 数据的映射，其次如果没有一个好的工具，创建、维护 XSLT 也是很费时费力
的事情。我现在的项目正在朝这个方向努力，希望能做一个象 Delphi 那样好用的，基于
XSLT 的 HTML 界面控件开发、管理、使用环境。
　　9、充分估计开发的艰辛程度
　　这个，一言难尽。总之实际需求的变化往往是超乎我们想象的，要在需求分析结束的
时候就清晰划分模块接口几乎做不到，计划不如变化。而 J2EE 体系架构是重量级的框架，
虽然 app server 实现了很多功能，但同时也要求你开发的时候付出额外的代价。对于
J2EE 项目的资金、时间、人手等资源估计，宁可多不可少，千万不要简单认为用了一个
weblogic 就万事大吉了。