Java Framework for Beginners

初学者如何开发出一个高质量的J2EE系统

板桥里人 http://www.jdon.com 2005/06/20

  J2EE学习者越来越多,J2EE本身技术不断在发展,涌现出各种概念,本文章试图从一种容易理解的角度对这些概念向初学者进行解释,以便掌握学习J2EE学习方向。

首先我们需要知道Java和J2EE是两个不同概念,Java不只是指一种语言,已经代表与微软不同的另外一个巨大阵营,所以Java有时是指一种软件系统的流派,当然目前主要是.NET和Java两大主流体系。

J2EE可以说指Java在数据库信息系统上实现,数据库信息系统从早期的dBase、到Delphi/VB等C/S结构,发展到B/S(Browser浏览器/Server服务器)结构,而J2EE主要是指B/S结构的实现。

J2EE又是一种框架和标准,框架类似API、库的概念,但是要超出它们。如果需要详细了解框架,可先从设计模式开始学习。

J2EE是一个虚的大的概念,J2EE标准主要有三种子技术标准:WEB技术、EJB技术和JMS,谈到J2EE应该说最终要落实到这三个子概念上。

这三种技术的每个技术在应用时都涉及两个部分:容器部分和应用部分,Web容器也是指Jsp/Servlet容器,你如果要开发一个Web应用,无论是编译或运行,都必须要有Jsp/Servlet库或API支持(除了JDK/J2SE以外)。

Web技术中除了Jsp/Servlet技术外,还需要JavaBeans或Java Class实现一些功能或者包装携带数据,所以Web技术最初裸体简称为Jsp/Servlet+JavaBeans系统。

谈到JavaBeans技术,就涉及到组件构件技术(component),这是Java的核心基础部分,很多软件设计概念(设计模式)都是通过JavaBeans实现的。

JavaBeans不属于J2EE概念范畴中,如果一个JavaBeans对象被Web技术(也就是Jsp/Servlet)调用,那么JavaBeans就运行在J2EE的Web容器中;如果它被EJB调用,它就运行在EJB容器中。

EJB(企业JavaBeans)是普通JavaBeans的一种提升和规范,因为企业信息系统开发中需要一个可伸缩的性能和事务、安全机制,这样能保证企业系统平滑发展,而不是发展到一种规模重新更换一套软件系统。

至此,JavaBeans组件发展到EJB后,并不是说以前的那种JavaBeans形式就消失了,这就自然形成了两种JavaBeans技术:EJB和POJO,POJO完全不同于EJB概念,指的是普通JavaBeans,而且这个JavaBeans不依附某种框架,或者干脆可以说:这个JavaBeans是你为这个应用程序单独开发创建的。

J2EE应用系统开发工具有很多:如JBuilder、Eclipse等,这些IDE首先是Java开发工具,也就是说,它们首要基本功能是可以开发出JavaBeans或Java class,但是如果要开发出J2EE系统,就要落实到要么是Web技术或EJB技术,那么就有可能要一些专门模块功能(如eclipse需要lomboz插件),最重要的是,因为J2EE系统区分为容器和应用两个部分,所以,在任何开发工具中开发J2EE都需要指定J2EE容器。

J2EE容器分为WEB容器和EJB容器,Tomcat/Resin是Web容器;JBoss是EJB容器+Web容器等,其中Web容器直接使用Tomcat实现的。所以你开发的Web应用程序可以在上面两种容器运行,而你开发的Web+EJB应用则只可以在JBoss服务器上运行,商业产品Websphere/Weblogic等和JBoss属于同一种性质。

J2EE容器也称为J2EE服务器,大部分时它们概念是一致的。

如果你的J2EE应用系统的数据库连接是通过JNDI获得,也就是说是从容器中获得,那么你的J2EE应用系统基本与数据库无关,如果你在你的J2EE应用系统耦合了数据库JDBC驱动的配置,那么你的J2EE应用系统就有数据库概念色彩,作为一个成熟需要推广的J2EE应用系统,不推荐和具体数据库耦合,当然这其中如何保证J2EE应用系统运行性能又是体现你的设计水平了。

衡量J2EE应用系统设计开发水平高低的标准就是:解耦性;你的应用系统各个功能是否能够彻底脱离?是否不相互依赖,也只有这样,才能体现可维护性、可拓展性的软件设计目标。

为了达到这个目的,诞生各种框架概念,J2EE框架标准将一个系统划分为WEB和EJB主要部分,当然我们有时不是以这个具体技术区分,而是从设计上抽象为表现层、服务层和持久层,这三个层次从一个高度将J2EE分离开来,实现解耦目的。

因此,我们实际编程中,也要将自己的功能向这三个层次上靠,做到大方向清楚,泾渭分明,但是没有技术上约束限制要做到这点是很不容易的,因此我们还是必须借助J2EE具体技术来实现,这时,你可以使用EJB规范实现服务层和持久层,Web技术实现表现层;

EJB为什么能将服务层从Jsp/Servlet手中分离出来,因为它对JavaBeans编码有强制的约束,现在有一种对JavaBeans弱约束,使用Ioc模式实现的(当然EJB 3.0也采取这种方式),在Ioc模式诞生前,一般都是通过工厂模式来对JavaBeans约束,形成一个服务层,这也是是Jive这样开源论坛设计原理之一。

由此,将服务层从表现层中分离出来目前有两种可选架构选择:管理普通JavaBeans(POJO)框架(如Spring、JdonFramework)以及管理EJB的EJB框架,因为EJB不只是框架,还是标准,而标准可以扩展发展,所以,这两种区别将来是可能模糊,被纳入同一个标准了。 但是,个人认为:标准制定是为某个目的服务的,总要牺牲一些换取另外一些,所以,这两种架构会长时间并存。

这两种架构分歧也曾经诞生一个新名词:完全POJO的系统也称为轻量级系统(lightweight),其实这个名词本身就没有一个严格定义,更多是一个吸引人的招牌,轻量是指容易学习容易使用吗?按照这个定义,其实轻量Spring等系统并不容易学习;而且EJB 3.0(依然叫EJB)以后的系统是否可称为轻量级了呢?

前面谈了服务层框架,使用服务层框架可以将JavaBeans从Jsp/Servlet中分离出来,而使用表现层框架则可以将Jsp中剩余的JavaBeans完全分离,这部分JavaBeans主要负责显示相关,一般是通过标签库(taglib)实现,不同框架有不同自己的标签库,Struts是应用比较广泛的一种表现层框架。

这样,表现层和服务层的分离是通过两种框架达到目的,剩余的就是持久层框架了,通过持久层的框架将数据库存储从服务层中分离出来是其目的,持久层框架有两种方向:直接自己编写JDBC等SQL语句(如iBatis);使用O/R Mapping技术实现的Hibernate和JDO技术;当然还有EJB中的实体Bean技术。

持久层框架目前呈现百花齐放,各有优缺点的现状,所以正如表现层框架一样,目前没有一个框架被指定为标准框架,当然,表现层框架现在又出来了一个JSF,它代表的页面组件概念是一个新的发展方向,但是复杂的实现让人有些忘而却步。

在所有这些J2EE技术中,虽然SUN公司发挥了很大的作用,不过总体来说:网络上有这样一个评价:SUN的理论天下无敌;SUN的产品用起来撞墙;对于初学者,特别是那些试图通过或已经通过SUN认证的初学者,赶快摆脱SUN的阴影,立即开溜,使用开源领域的产品来实现自己的应用系统。

最后,你的J2EE应用系统如果采取上面提到的表现层、服务层和持久层的框架实现,基本你也可以在无需深刻掌握设计模式的情况下开发出一个高质量的应用系统了。

还要注意的是: 开发出一个高质量的J2EE系统还需要正确的业务需求理解,那么域建模提供了一种比较切实可行的正确理解业务需求的方法,相关详细知识可从UML角度结合理解。

当然,如果你想设计自己的行业框架,那么第一步从设计模式开始吧,因为设计模式提供你一个实现JavaBeans或类之间解耦参考实现方法,当你学会了系统基本单元JavaBean或类之间解耦时,那么系统模块之间的解耦你就可能掌握,进而你就可以实现行业框架的提炼了,这又是另外一个发展方向了。

以上理念可以总结为一句话:
J2EE开发三件宝: Domain Model(域建模)、patterns(模式)和framework(框架)。

推荐一套高质量的J2EE开源系统: JPestore

如果初学者没有理解,欢迎继续讨论,大胆提出你心中的疑问。

Advertisements

JAVA architechture

Java企业系统架构选择考量

板桥里人 http://www.jdon.com 2005/09/26

  现在Java领域各种技术百花齐放,名目繁多,如何根据自己的需求选择这些框架呢?特别对于初学者,在学习选择方向上也非常迷茫,如何有针对性的根据自己项目特点进行学习就变的更加重要。

  下面我们从一个发展角度来对J2EE/Java EE的这些框架诞生进行一番考量,可能对我们的选择有很大帮助。

  首先我们需要明白一个高质量的J2EE系统是什么样子?高质量的J2EE/Java EE系统标准实际就是OO设计的标准,松耦合是OO设计的主要追求目标之一,那么无疑解耦性成为衡量J2EE/JEE质量的首要标准。实际选择中,还需要兼顾可伸缩性/性能/开发效率等方面综合考虑。

  J2EE/Java EE号称多层结构,为什么多层比两层好?因为多层结构解耦性好,带来维护拓展方便灵活。

  典型的J2EE/Java EE至少划分三个层次:表现层/业务逻辑组件层/持久层。

  如图,表现层英文是Presentation Layer,是实现显示功能的,这部分一般使用B/S结构来完成,当然你也可以使用专门远程客户端来实现;

  业务逻辑层因为是由大量组件(Components)组成的,也可称为组件层,组件从不同角度又可分为各种类型,然后又有不同的流派,目前占主要位置的是Model+Service,模型加服务,所以这一层又称为业务服务层Business Service;也有称为Model业务层;

  持久层是负责对象持久化也就是数据库操作的层次,英文Persistence Layer

  SUN伙伴们推出J2EE标准时,分别对这三个层次规定了标准实现,表现层使用Jsp/Servlet技术;业务组件层使用EJB的会话Bean;持久层使用实体Bean。同时,标准将业务层和持久层在物理上组成一个新的容器EJB容器,与表现层技术完全一样的容器,这样,J2EE技术被细化为WebEJB,物理上有Web容器和Web应用程序;以及EJB容器和EJB应用程序。

  当然,J2EE/JEE的发展不止这些,这三个层次技术分别独立发展,高歌猛进,下面分别单独陈述,当你了解某种框架技术为什么诞生时,你可能就知道你该在什么情况下选择它们了,工具总是因目的而生!

表现层框架

  J2EE/Java EE虽是多层结构,但它不是一种强制性多层结构,也就是说,你也可能做成传统两层结构,有的初学者直接使用Jsp嵌入Java代码调用数据库这样结构实际不是多层结构,还是以前的两层结构。

  在Jsp中嵌入大量代码,一旦报空指针错误就很难找出问题,很多初学者下载JiveJdon 2.5后就经常碰到这个问题,因此大量有关空指针错误问题出现论坛里,为什么他们不能自己解决呢? 那是因为无法定位错误在Jsp中的位置,Tomcat等服务器只告诉我们错误在index_jsp.java(Jspjava文件)位置,搞得一些人经常会跑到Tomcat服务器内部翻找JspJava文件,这一过程无比痛苦(为了减少初学者这种痛苦,本站暂停了JiveJdon2.5的下载)。

  J2EE/Java EE的发展就是降低这种痛苦,首先想到的方式是:在Jsp调试上下苦功,要求Tomcat等服务器提供详细的错误定位;可惜到Tomcat 5.5我们也没看到这种功能;实际上,根本解决之道就是将Jsp的调试变成java组件的调试。

  首先通过MVC模式规定Jsp只能等同于Html,不能包含Java代码,将JspJava代码分离,可是这样分离之后,它们结合起来又麻烦了,所以,虽然你使用MVC模式,但是还是直接基于Jsp技术,带来的是开发效率的降低。

  Struts框架解决了这个问题,通过ActionForm可以将JspJavaBeans方便快速地结合起来,但是有人又抱怨StrutsActionForm限制太死,与Jsp虽能对应,只能一个ActionForm一个表单对应,而不能任意组件JavaBeans都可以和Jsp任意字段对应,这时就出来了组件型框架JSF/Tapestry

  表现层框架Struts/Tapestry/JSF架构比较

Struts/Tapestry/JSF是目前J2EE表现层新老组合的框架技术。从诞生时间上看,Struts应该比较早,使用得非常广泛,Tapestry 3.0逐渐引起广泛的重视,正当Tapestry即将大显身手时期,SUN推出JSF标准技术,虽然JSF一开始推出尚不成熟,留出了一段空白期,但是随着JSF1.1标准推出,JSF开始正面出击,粉面隆重登场了。

  其实,JSF和Tapestry也并不是那种头碰头的相同竞争性技术,两者还是各有侧重点的,不过比较细微,但是这种细微点在实现一个大工程时可能带来不同的感受和变化。

  首先,我们从一个高度来抽象一下表现层框架应有的技术架构,下图可以说所有表现层框架技术都必须实现的功能架构图:

 

  当然,我们不必废话罗嗦MVC模式,MVC模式是基准模式,现在框架技术已经不必再拼是否是MVC模式了。 在上图MVC模式基础上,一个表现层框架无外乎要实现图中的三个功能:

1.在当前页面能够显示一个组件对象的内容;而不是象纯JSP那样,需要在Jsp页面写入“调用对象方法”的Java代码。

2.当用户按下页面的提交按扭或链接后,事件发生,这时应该触发服务器端并将当前页面的参数提交给服务器。这种机制表现在Form表单提交和有参数的链接<a href=””></a>

3.从一个页面视图直接跳转到另外一个页面视图,单纯的导航作用。

我们通过下表来比较这 三种框架在实现上图各个功能时技术细节,从而得出他们的异同点和偏重点。

  Struts Tapestry3.0 JSF
在View显示的组件要求 组件必须继承ActionForm 分显式调用和隐式调用
组件必须继承BaseComponent
普通POJO
无需继承
Managed Bean
组件在View显示粒度 View页面只能显示与表单对应的ActionForm,配置中Action ActionForm 页面一般只能1:1:1关系。 可将组件嵌入页面任何一行,对使用组件数量无限制。 同Tapestry
页面分区tiles 使用Tiles标签库实现,需要另外tiles-def.xml配置文件 组件有自己的视图页面,通过调用组件即直接实现多个页面组合。强大自然的页面组合是其特点。 通过组件+标签库实现Subview,但如需重用Layout,还要结合Tiles.
页面跳转 使用标签库html:link中写明目标URL,URL名称需要对照配置文件的path命名,与组件Action耦合。 URL名称是目标的组件名称,不涉及URL和路径等操作,方便稳固。 类似Struts,也需要在配置文件中查找,与组件分离。
参数传递 使用html:link时传递参数超过一个以上处理麻烦。 直接调用组件,直接赋予参数,没有参数个数限制 参数分离传递给组件
事件触发 通过表单提交submit激活,不能细化到表单里字段。 能够给于表单每个字段贴一个事件,事件组件必须实现PageListener接口 同Tapestry,事件组件必须实习ActionListener 接口

Struts组件编程模型

  Struts实现组件编程时有一些复杂:经常为一个页面中需要引入多个组件而头疼,因为Struts中无法直接引入多个组件,必须绕一些圈子:

  一般分两种情况:如果同一个Action就可以对付这些组件,那么在这种情况下有两个办法:

1.将这多个组件装入一个ActionForm中,如使用MapForm等机制;

2.手工将多个组件装入request/session等scope中,然后根据其名称在jsp中获得。

  这两个方法都有缺点: 第一种办法经常一个ActionForm弄得面目全非,变成一个大杂烩,违反了OO分派封装的原则;第2种办法其实又回到jsp编程;

  第二种情况,如果这些组件必须有预先由不同的Action来处理,每个组件必须经过Action –>ActionForm流程,在这种情况下有两种办法:

1.使用Tiles, 不同流程输出到同一个页面的不同区域。是一种并行处理方式。

2. 对多个流程首尾相连,第一Action forward结果是第二个Action,最后输出一个Jsp,在这个jsp中就可以使用前面多个流程的多个ActionForm了,这属于串行方式。

Struts组件模型缺点

  Struts组件编程必须限定在Action/ActionForm/JSP这三个框框中做文章,难度相对比较大,而Tapestry/JSF则没有太多这些技术框框限制,两者在组件编程方面更让编程者自由一些,方便一些,这也是组件型框架的优势吧。

Struts标签库

  在Struts中,经常需要使用标签库来显示组件ActionForm中内容,这就涉及到一个结合的问题,标签库是别人写的,参考Struts的标签库用法,而组件是自己的,难度和麻烦就体现在这个结合点上。

  JSF基本思路和Struts差不多,只不过换了不同标签库,也需要标签库+组件的结合思考,不过因为组件这里是通用组件,没有什么限制,所以这样比Struts要轻松一些。

  Tapestry使用了组件库概念替代了标签库,没有标签库概念,这样就没有标签库和自己的组件需要结合的问题,都是组件的使用,组件中分Tapestry标准组件和自己定义的组件,这也是接触了Jsp体系的人学习Tapestry面临的一个思路转换。

  具体以页面跳转为例子,页面跳转是靠链接<a href=”目标”></a> 实现,链接是页面经常使用的元素。

  Struts提供的html:link在频繁使用就特别不方便,尤其在传递多个参数时:其中html:link的page值,是跳转对方页面或Action的path,这个path一般需要到struts-config.xml查找Action的相应path,一旦配置文件path值修改,涉及到这个所有相关页面都要修改。

  JSF将链接概念划分两个方面:导航性质和事件激活,在导航方面还是需要到配置faces-config查询Navigation的from-outcome的值。

  由于Tapestry没有标签库概念,只有组件或页面两个概念,因此,链接跳转目标要么是组件,要么是页面,简洁简单,它没有多余的path概念,就是组件名,也就是对象名称,组件名称和path名称合二为一。

总结

  JSF在很大程度上类似Struts,而不是类似Tapestry,可以说是一种Struts 2.0,都是采取标签库+组件的形式,只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制;JSF在事件粒度上要细腻,不象Struts那样,一个表单一个事件,JSF可以细化到表单中的每个字段上。

  JSF只有在组件和事件机制这个概念上类似Tapestry,但是不似Tapestry那样是一个完全组件的框架,所以,如果你做一个对页面要求灵活度相当高的系统,选用Tapestry是第一考虑。

  Struts/JSF则适合在一般的数据页面录入的系统中,对于Struts和JSF的选用,我目前个人观点是:如果你是一个新的系统,可以直接从JSF开始;如果你已经使用Struts,不必转换,如果需要切换,可以将JSF和Tapestry一起考虑。

  另外,JSF/Tapestry不只是支持Html,也支持多种客户端语言如WML或XUI等。

  这三者之间关系:如果说Struts是左派;那Tapestry则是右派;而JSF则是中间派,中庸主义是SUN联盟的一贯策略。

  当然,你也可以发表你在实践中这三者任何一个的使用感受,以使得后来者有一个比较。

 

 

业务逻辑层框架

可伸缩性

  因为EJB标准的推出,业务组件层以前基本是EJB的天下,但是EJB功能实在太强大,它考虑了世界顶级大型系统需求,因此免不了显得很复杂,当初,基本上所有的大型企业高端都是选用J2EE,选用J2EE实际是选用EJBEJB强调的高可伸缩性为大型企业日益发展提供最大的发展空间,不再因为企业快速发展导致整个企业系统结构都要发生根本变化,这是使用EJB的现实优势。

  这种企业系统的可伸缩性不是因为EJB存在才显得重要,而是我们企业架构选择需要考量的基本因素。换句话说,无论我们使用EJB与否,这个问题都需要考虑:一台服务器不够用怎么办?如果这台服务器死机会对企业运营带来什么影响?如果每个星期这台服务器停机维护升级会不会对企业带来打击?我的企业系统是不是需要可靠的、几乎不当机的7×24运行?当企业系统面对大量外部访问用户时,一台服务器是否够用?多台服务器联动的需求是否涉及软件技术更换?

  在这个现实因素考量后,如果觉得不是很重要,或者说将来一段时间内这些因素无所谓,那么可以不选用EJB了。

  为什么有不选用EJB的理由?因为它复杂,学习起来比较困难,EJB帮助我们考虑企业中可能碰到的大部分问题,实际上,有的我们不需要,这也就是为什么说EJB是一个重量级解决方案所在。

  与重量级相比的是轻量,业务组件层轻量级解决方案有Spring/HiveMidn/Jdon Framework等,轻量一词曾经因为EJB的出现而变得时髦,给人造成的感觉是:EJB花了老鼻子力气完成的那些功能,使用我轻量级解决方案可以轻而易举也能解决,举重若轻啊,其实这是一种误解。

  当曾经以轻量自居的Spring将事务机制纳入自己怀抱中时,它也开始低调轻量了,实际是不轻不重了;当然如果它把分布式计算和事务再次加入时,天平砝码也会沉下去的。

  初学者总是愿意使用简单的解决方案,学习使用方便,因此比较喜欢轻量级框架技术,这是正常的,但是在使用轻量级别框架之前必须明白:你的系统将来真的只需要一台服务器即可?你的项目完成期真的非常紧急?

  如果只需要一台巨强服务器,就不必选择EJBEJB是因分布式多服务器而生,对于单台服务器,缺乏本地透明性,也就是说:你无法透过EJB直接和本地JVM或文件系统等打交道,透明性也是衡量一个框架的重要指标。

  当然,重量和轻量并不完全对立,EJB3就是为了简化J2EE的使用,使得EJB不只是擅长处理大型企业系统,中小型系统也使用很方便,这实际上也是EJB轻量化的一种努力。什么是Java EE 5

  所以,对于架构选择来说,根本前提是需要明白你的系统现在或将来一段时间(注意需要考虑将来一段时间,不能只看眼前)是中小型系统还是大型系统?

灵活性/定制性/透明性

  当然这个答案有时我们自己也可能很难给出,那么我们还需要从其他角度来考量EJB和非EJB之选,例如笔者曾经经历一个大型实时娱乐平台社区系统,从规模上说肯定是大型系统,设计目标10万人在线,从这个角度非选用EJB不可!

  但是,EJB因为还有事务机制,虽然应用程序可以选择失效EJB事务,但是EJB容器设计因为考虑了事务,所以在其内核上总是会显得臃肿,是一种累赘,这也是一种重量表示,不需要的东西存在肯定会影响效率,那么难道我不能根据我的需求,对EJB整体包括EJB容器进行可配置式的切割?也就是说,我上面这个案例只需要EJB的分布式计算功能,其他的功能我都拆除,只剩余我需要的功能能运行就可以了,轻装上阵。

  可惜,这种任意切割,应需而定的目标在EJB3标准还没有被重视,所幸的是,Ioc/AOP技术为这种目标实现提供了实现可能,但是,只有Ioc/AOP还是不够,特别是看Ioc的范围,如果你只把应用系统组件纳入Ioc管理时,自由解耦只属于应用系统,我上面案例的目标还是无法达到,当你把框架本身组件也纳入Ioc管理时,任意切割,应需而定的目标才真正实现。

  SpringEJB3属于只把应用系统组件纳入Ioc管理,这从JBoss 4.0版本可以看出;那什么框架会把框架本身组件也纳入Ioc管理呢?ApacheHivemind和笔者开发的Jdon框架

  什么样的组件可以被纳入Ioc管理呢?POJO组件,POJO这个概念其实当初是针对EJB缺点而推出,EJB要求应用系统的组件必须继承或依赖EJB容器,这样使得调试变的不方便,但是后来,POJO的概念已经不只最初这些概念,POJO代表那种与周围完全脱离关系、自由自在的Object了,如果应用系统的Model或者Service都是POJO,意味着你的应用系统不依赖任何其他系统,解耦性灵活性高。

  POJO是因为EJB而提出的,当EJB自己倾向POJO时,大家都在宣称自己是POJO时,POJO概念就没有立足点了,这也是Java领域哭笑不得的现象,但是我个人更倾向把非EJBJavaBeans组件通称为POJO

  HivemindIoc依赖注射部分功能和Jdon框架非常类似,当上百个POJO组件配置时,完全不必指定它们之间的依赖关系;你可以将自己应用程序的组件注册到Registry中,这样Hivemind将帮助你启动这些组件,正如你在Jdon框架中将你的组件写入mycontainer.xml中,Jdon框架也将自动启动你这些组件,并解决它们之间的互相调用,包括和框架本身组件互动。

  HiveMindJdon框架定义的POJO Service有如下特点:

  不象EJB那样缺乏本地透明化(location transparency)概念,这些POJO Service总是能定位到同样一个JVM;也不象基于XMLWeb服务web services那样没有语言透明(language transparency)概念,这些POJO Service总是可以被一组Java接口来概括替代(通过调用Java interface来替代调用这些具体Service);当然,更不会类似JMXJini,不能进行service的热装载( hot-loading)。

  注意:当Ioc/AOP提供高度灵活的同时,已经有初学者开始抱怨Spring的过分灵活,那么比Spring在组件上更灵活的Jdon框架只能算是一种追求极端,它不一定构成你进行架构选择的主要依据!

  上面这些讨论只是表明在灵活性(解耦性/透明性)这条需求道路上深究下去的选择,你自己的应用系统需求会产生各种不同的要求,有些要求甚至是极致的,这种偏向程度就成为你架构选择的目标,如果你的这种极致要求在目前Java世界里还没有可选框架时,那么你就要动手自己做了,这也说明什么时候你开始自己做框架(如Jdon框架),虽然在大多数情况下我们是不必要自己发明轮子的。

 

快速构建性

  前面是从灵活性和定制性这个角度讨论架构选择目标,但是在一般情况下,我们还是从上手难易、开发效率这个角度来进行架构选择,从这个角度来说,就是需要我们将选用的框架尽可能的多帮助我们实现一些功能,但这又是和使用难易是矛盾的,因此有个取舍问题,取舍有个准则:这个框架尽量能提供越多功能;尽量需要我们少写代码,甚至不写代码(使用XML配置),少动脑筋。

  关于XML配置这里也涉及难易问题,XML配置语法不能太复杂,有太多小开关Switch也增加学习成本。

  从这个角度看,EJB无论是EJB2EJB3提供的功能是最齐全的,但是XML配置开关太多 Spring属于中等,组件XML配置不算简单,但是因为有不少Struts+Spring+Hibernate之类现成开源代码可供参考,因此学习起来难度也不大,Spring越来越象一个J2EE API(注意,JDKJ2SE API Spring除不能提供分布式计算外,也因为过分灵活降低了一些开发效率,例如它的组件依赖关系一般需要逐步指定,auotwiring功能还没有深入骨髓成为核心功能。Ioc容器的革命性优点。

  Spring除了提供组件层功能以外,还有表现层支持Spring MVC;也有持久层实现的JDBC模板,这样,整个J2EE/Java EE系统各个层次Spring都提供了缺省实现,在这方面无疑提高了开发效率,但是Spring提供丰富API目的好像不是为了快速开发,而是为了建立一个完整的功能齐全的API功能库。正如它网页上开头文字所述:As the leading full-stack Java/J2EE application framework,注意full-stack(完整齐全)是它突出的名词。

  那么,还有另外一个空白,就是以开发效率为主要考虑,这类框架除了必须考虑足够灵活性和丰富功能以外,宗旨是为了在一般缺省情况下快速完成一个J2EE/Java EE系统,这非常类似MDA工具了,但是一个完全丧失灵活性和定制性的MDA工具也不是我们欢迎的。

  Jdon框架的发展目标是为了填补这个空白,相信也会越来越多框架向这个目标迈进,当然不可否认,Spring也可能调转枪头走入这个领域,EJB2/EJB3正依靠JBuilder等这样商业化开发工具向这个领域靠拢,这个发展方向实际是4GL RAD Tools

  很多人在快速构建方面也很早进行了探索,涌现出各种工具:如何构建一个快速业务构件平台? 但是如何把快速构建和构件(组件)灵活性有机结合在一起?它是考验一个业务构件(业务组件)平台好坏的准则。有些构件平台虽然开发迅速,但是对于特殊情况,可供程序员定制透明操作部分不多,很死,典型的是两层结构以前的Delphi,开发很快速,但是无法象J2EE这样深入到系统各个层次进行定制/维护/拓展!

业务组件框架对比

  EJB2/EJB3 Spring Framework Jdon Framework

灵活性
(
松耦合)

EJB3EJB2更具灵活性,EJB3支持应用系统POJO 支持应用系统POJO,框架基础功能不能替换 支持应用系统POJO,框架本身可分离配置,定制性更强

功能完整性

全面,支持异步JMS 分布式事务 较为全面。有自己的表现层和持久层模板,可支持异步 基本完整,表现层借助Struts实现。有自己简单的持久层模板

单台性能

一般,批量查询等大数据量业务处理须小心,存在本地不透明缺陷。 一般,框架本身组件无性能提升极致,应用程序可配置cache/Pool 好,框架本身组件使用缓存提升性能,应用程序可配置cache/Pool,批量查询专门优化,适合实时性并发性要求较高应用

可伸缩性

可支持多台服务器分布式计算。 不支持,可依靠EJB实现 不支持,可依靠EJB实现

开发效率

学习曲线长,导致熟练掌握难。借助商业开发工具可加快熟练者的开发速度。 较为复杂,可挑选只适合自己的功能实现。当组件很多时,需要照顾这些组件之间调用关系。 简单快速,表现层编码很少。当组件个数很多时,无需照顾它们之间的调用关系

系统规模

EJB2适合大型系统;EJB3适合中大型系统 适合中小型系统 适合小中型系统,建立一个简单的网站系统等,和EJB无缝结合,可借助EJB支持中大型系统

重量级别

重量,正在减肥 轻量偏重,有可能继续增肥 最轻量,恪守简单快速原则

 

持久层框架

  持久层框架目前有EJB2/EJB3的实体BeanHibernate和各种JDO产品,当然还有直接写SQL语句的JDBC,如iBatis等。

  持久层框架质量好与坏区分就是是否是O/R Mapping,也就是对象和关系数据库映射,关系数据库需要实现定义好Schema结构;对象因为字段而变的也有一个自己的结构,如何将对象数据自动持久化到数据库中,首先我们得定义两者结构的对应,这实际是数据的元数据定义。

  因为Hiberante/Toplink/JDO这样O/R Mapping工具帮助你实现对象和数据库转换,克服了对象和数据库阻抗现象,O/R Mapping总结 ,所以才使得我们更多的可以对象方式(从模型Model对象)来考虑Java EE/J2EE系统,可以完全放弃以前那种以数据库为中心的思维方式:数据库时代的终结。

  所以,是否选用好的持久层框架,取决于你整个团队思维是否彻底OO了,是否需要真正OO,当然,对于一些小型项目,有时我们觉得直接使用JDBC模板反而更加轻松快捷一点,这也是SpringJDBC模板/iBatis/JdonJdbc模板存在的理由了。

例如新增一个数据表,在Jdon框架只需要下面几行代码即可:

 

String sql = “INSERT INTO testuser (userId , name) VALUES (?, ?)”;
List queryParams = new ArrayList();
queryParams.add(userTest.getUserId());
queryParams.add(userTest.getName());
jdbcTemp.operate(queryParams,sql);

 

  这种方式和O/R Mapping兴师动众的多个XML配置和关系映射思考相比,对于习惯SQL语句的程序员反而更加迅速。

  从以上可以看出,灵活性/快速性/简单性/可伸缩性是我们进行架构选择的主要几个依据,架构选择实际就是在这几个策略之间做一个平衡。当然,还有一个非常重要的因素,因为它不属于某个层次的技术,性能/缓存是必须和上面因素综合考虑的因素。

  因为性能最初是我们使用计算机的基本原因,别忘记这个根本。