对J2EE项目的一些体会

　　1、认真考虑是否真要使用J2EE

　　这个很重要，非常重要
。象EJB级的权限控制，如
信任问题，那么基本上就不
么用处。针对项目的实际情
先进技术。

。J2EE涵盖的内容大而全，但很
果你的表现层（大部分项目就是
用考虑。又比如伸缩性，如果同
况选择效费比最合适的解决方案

多不一定就是具体实际项目需要的
Web server）和应用服务器不存在
时在线最多不超过100个，就没什
，而不要为了应用先进技术而应用

　　2、选择合适的分布模型

　　提起分布，很多人可能
server C处理仓储；如果B
server D，统计、分析部分
必须（如分支机构统一通过
放在一个app server中，能
分布——即集群中的所有ap
平行分布的可靠性、容错能
，减少了因为业务逻辑层内
业务逻辑必须相互独立部署
布还是必不可少的。

都会有这样的设想：server A处
的负载太大，那么再细分一下：
的部署在server E，等等。其实
总部的app server来进行权限验
在一个进程空间内更好（使用ho
p server功能上都是等价的。相
力、伸缩能力都要更好，同时减
部跨进程调用引起的开销，提高
、管理，b、负载较为集中地分

理认证，server B处理订单，
录入、修改部分的EJB部署在
没有必要，我的体会是：除非业务
证），否则最好将所有的应用全部
me interface），然后进行平行的
比前一种垂直（或者网状）分布，
少了部署、管理负担。最重要的是
了整体性能。然而，如果a、一些
布在若干个EJB中，那么，垂直分

　　3、为Entity bean选择合适的数据存储方案

　　首先尽量使用CMP管理
体，不然光insert update
、一对多关系，如果你的ap
发，象Cocobase, EJB crea
老实实写代码吧……

数据存储，尤其是简单的，大部
就够你忙的了，更不用说数据库
p server没有实现EJB2.0规范，
tor等等，可以提高不少效率。

分业务操作都是插入删除修改的实
移植问题。其次对于简单的一对一
可以考虑使用O/R映射工具帮助开
对于复杂的对象存储，没办法，老

　　4、慎重考虑EJBHome.findByXXX()，listXXX()的实现

　　设想对一个百万记录级的表进行检索
耗费资源的过程；同时对于检索到的每一
程调用，开销可想而知。为什么有的人觉
主要原因之一。

，结果集很可能是上万条、十万条，这本身就是一个
个记录还要做一次findByPrimarykey，这么多次跨进
得用J2EE实现的程序奇慢无比，缺乏仔细的设计就是

　　5、使用抽象数据结构传递数据

　　例如，listOrder()返回Collection
参数而不是LinkedList。当然这个实际上

而不是Vector，insertItems()也是以Collection为
与J2EE本身关系不是很大。

　　6、对Entity bean尽量使用Map来存储、传递属性

　　对业务流程没有很大影
，而不要直接用成员变量+g
法，实现、维护都是代价高
维护get/set方法可能就会
的入职日期决定其休假天数

响的属性，象身高体重出生年月
etXXX/setXXX。对于ejbCreate
昂的。需知实际应用中这些字段
让你吐血了。但是，对于对业务
的计算，那么还是作为成员变量

之类，最好用一个HashMap来存放
也是一样，十几个参数的create方
的增减、属性变化是家常便饭，光
流程有关建意义的字段，例如员工
的好。

　　推荐一个关于EJB设计模式的好地方：

　　http://www.theserverside.com/res

ources/patterns_review.jsp

　　7、分清Entity bean和session bean的职责

　　Entity bean是实体的
数据的接口（所以我认为它
现有其他Entity bean参与
”变为“生效”，同时将订
对象参与：客户，订单和积
还是订单？都不合适，如果
的接口；如果在客户对象中
分接口或者折算策略的接口
OrderProcessor来管理订单
解所有参与订单处理的对象
生效之前要通过审批，这种
接口发生了变化，也不会影

对象形式，它的职责应限于自身
本质上应该属于数据存储层）。
的业务逻辑。例如，订单的货款
单的金额按照某种规则折算成该
分折算策略。那么，实现流程的
在订单中，那么订单对象需要了
也是一样。耦合度增强就意味着
改变了，那么改变就会蔓延到订
处理流程，以stateless sessio
的接口，它集中管理对订单的处
变化不会影响到参与流程的实体
响到其他对象。

的存储，以及对外部提供访问内部
Entity bean应该尽量避免自己实
收到以后，将订单的状态由“提交
客户的积分。这个业务流程有三个
方法应该在哪个对象中呢，是客户
解客户积分属性的接口及积分折算
维护难度增大，如果用户对象的积
单对象中。合适的方式是用一个
n bean来实现。OrderProcessor了
理流程，如果流程发生变化，订单
对象；同样，参与流程的某个对象

　　8、重视表现层的复用

　　企业软件的界面，大部
合而来。如果能合理采用一
于统一维护界面风格。对J2
本上就是文件包含、创建类
直接方法调用来的方便）等
Velocity、Enhydra、WebMa
界面元素类库，但自己项目

分都可以用一些基本元素如grid
些技术对这些元素进行复用，不
EE的表现层，也就是JSP/servle
库、Tag lig（本质上还是创建
等。还有一些不同于JSP/servle
cro等等，也可以参考。虽然Jav
内部统一使用某种方案还是可能

, tree, page control, form等组
但有利于降低开发成本，而且也便
t，可以采用的复用技术不多，基
类库，使用起来我觉得还不一定有
t的表现层框架，如Apache
a还没有一个规范的、统一的HTML
的。

　　另外，XML+XSLT也是一
后再用XSLT模版转化成最终
型语言方法调用带来的参数
式的数据集在app server中
换引入的性能负担。同时XM
如从J2EE移植到.Net或者相
能。问题在于首先要管理关
创建、维护XSLT也是很费时
Delphi那样好用的，基于XS

种方案。将数据直接用XML形式
界面。XML与XSLT之间属于模式
类型、个数、顺序限制，做到彻
可以按照合适的方案进行缓冲，
L和XSLT是业界广泛采纳的标准
反），表现层的XSLT形式的界面
系型数据到层次型XML数据的映
费力的事情。我现在的项目正在
LT的HTML界面控件开发、管理、

表现出来，绕过Entity bean，然
匹配式的松散耦合，可以避免强类
底地数据与界面分离；同时XML形
避免频繁访问数据库，抵销XSLT转
，如果今后采用不同的体系结构（
可以重用。JSP或ASP就没有这种可
射，其次如果没有一个好的工具，
朝这个方向努力，希望能做一个象
使用环境。

　　9、充分估计开发的艰辛程度

　　这个，一言难尽。总之实际需求的变
就清晰划分模块接口几乎做不到，计划不
server实现了很多功能，但同时也要求你
时间、人手等资源估计，宁可多不可少，

化往往是超乎我们想象的，要在需求分析结束的时候
如变化。而J2EE体系架构是重量级的框架，虽然app
开发的时候付出额外的代价。对于J2EE项目的资金、
千万不要简单认为用了一个weblogic就万事大吉了。

　　以上是我的一些粗浅看法和体会，希
肯定不少，还请见谅。

望能同大家交流讨论。限于本人水平，错误不当之处