对J2EE项目的一些体会
、认真考虑是否真要使用J2EE
这个很重要,非常重要。J2EE涵盖的内容大而全,但很多不一定就是具体实际项目需要的。象EJB级的权限控制,如果你的表现层(大部分项目就是Web server)和应用服务器不存在信任问题,那么基本上就不用考虑。又比如伸缩性,如果同时在线最多不超过100个,就没什么用处。针对项目的实际情况选择效费比最合适的解决方案,而不要为了应用先进技术而应用先进技术。
2、选择合适的分布模型
提起分布,很多人可能都会有这样的设想:server A处理认证,server B处理订单,server C处理仓储;如果B的负载太大,那么再细分一下:录入、修改部分的EJB部署在server D,统计、分析部分的部署在server E,等等。其实没有必要,我的体会是:除非业务必须(如分支机构统一通过总部的app server来进行权限验证),否则最好将所有的应用全部放在一个app server中,能在一个进程空间内更好(使用home interface),然后进行平行的分布――即集群中的所有app server功能上都是等价的。相比前一种垂直(或者网状)分布,平行分布的可靠性、容错能力、伸缩能力都要更好,同时减少了部署、管理负担。最重要的是,减少了因为业务逻辑层内部跨进程调用引起的开销,提高了整体性能。然而,如果a、一些业务逻辑必须相互独立部署、管理,b、负载较为集中地分布在若干个EJB中,那么,垂直分布还是必不可少的。
3、为Entity bean选择合适的数据存储方案
首先尽量使用CMP管理数据存储,尤其是简单的,大部分业务操作都是插入删除修改的实体,不然光insert update就够你忙的了,更不用说数据库移植问题。其次对于简单的一对一、一对多关系,如果你的app server没有实现EJB2.0规范,可以考虑使用O/R映射工具帮助开发,象Cocobase, EJB creator等等,可以提高不少效率。对于复杂的对象存储,没办法,老老实实写代码吧……
4、慎重考虑EJBHome.findByXXX(),listXXX()的实现
设想对一个百万记录级的表进行检索,结果集很可能是上万条、十万条,这本身就是一个耗费资源的过程;同时对于检索到的每一个记录还要做一次findByPrimarykey,这么多次跨进程调用,开销可想而知。为什么有的人觉得用J2EE实现的程序奇慢无比,缺乏仔细的设计就是主要原因之一。
5、使用抽象数据结构传递数据
例如,listOrder()返回Collection而不是Vector,insertItems()也是以Collection为参数而不是LinkedList。当然这个实际上与J2EE本身关系不是很大。
6、对Entity bean尽量使用Map来存储、传递属性
对业务流程没有很大影响的属性,象身高体重出生年月之类,最好用一个HashMap来存放,而不要直接用成员变量+getXXX/setXXX。对于ejbCreate也是一样,十几个参数的create方法,实现、维护都是代价高昂的。需知实际应用中这些字段的增减、属性变化是家常便饭,光维护get/set方法可能就会让你吐血了。但是,对于对业务流程有关建意义的字段,例如员工的入职日期决定其休假天数的计算,那么还是作为成员变量的好。
推荐一个关于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就万事大吉了。
、认真考虑是否真要使用J2EE
这个很重要,非常重要。J2EE涵盖的内容大而全,但很多不一定就是具体实际项目需要的。象EJB级的权限控制,如果你的表现层(大部分项目就是Web server)和应用服务器不存在信任问题,那么基本上就不用考虑。又比如伸缩性,如果同时在线最多不超过100个,就没什么用处。针对项目的实际情况选择效费比最合适的解决方案,而不要为了应用先进技术而应用先进技术。
2、选择合适的分布模型
提起分布,很多人可能都会有这样的设想:server A处理认证,server B处理订单,server C处理仓储;如果B的负载太大,那么再细分一下:录入、修改部分的EJB部署在server D,统计、分析部分的部署在server E,等等。其实没有必要,我的体会是:除非业务必须(如分支机构统一通过总部的app server来进行权限验证),否则最好将所有的应用全部放在一个app server中,能在一个进程空间内更好(使用home interface),然后进行平行的分布――即集群中的所有app server功能上都是等价的。相比前一种垂直(或者网状)分布,平行分布的可靠性、容错能力、伸缩能力都要更好,同时减少了部署、管理负担。最重要的是,减少了因为业务逻辑层内部跨进程调用引起的开销,提高了整体性能。然而,如果a、一些业务逻辑必须相互独立部署、管理,b、负载较为集中地分布在若干个EJB中,那么,垂直分布还是必不可少的。
3、为Entity bean选择合适的数据存储方案
首先尽量使用CMP管理数据存储,尤其是简单的,大部分业务操作都是插入删除修改的实体,不然光insert update就够你忙的了,更不用说数据库移植问题。其次对于简单的一对一、一对多关系,如果你的app server没有实现EJB2.0规范,可以考虑使用O/R映射工具帮助开发,象Cocobase, EJB creator等等,可以提高不少效率。对于复杂的对象存储,没办法,老老实实写代码吧……
4、慎重考虑EJBHome.findByXXX(),listXXX()的实现
设想对一个百万记录级的表进行检索,结果集很可能是上万条、十万条,这本身就是一个耗费资源的过程;同时对于检索到的每一个记录还要做一次findByPrimarykey,这么多次跨进程调用,开销可想而知。为什么有的人觉得用J2EE实现的程序奇慢无比,缺乏仔细的设计就是主要原因之一。
5、使用抽象数据结构传递数据
例如,listOrder()返回Collection而不是Vector,insertItems()也是以Collection为参数而不是LinkedList。当然这个实际上与J2EE本身关系不是很大。
6、对Entity bean尽量使用Map来存储、传递属性
对业务流程没有很大影响的属性,象身高体重出生年月之类,最好用一个HashMap来存放,而不要直接用成员变量+getXXX/setXXX。对于ejbCreate也是一样,十几个参数的create方法,实现、维护都是代价高昂的。需知实际应用中这些字段的增减、属性变化是家常便饭,光维护get/set方法可能就会让你吐血了。但是,对于对业务流程有关建意义的字段,例如员工的入职日期决定其休假天数的计算,那么还是作为成员变量的好。
推荐一个关于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就万事大吉了。