2006
年
5
月,
Java EE 5
规范正式发布。
Java EE 5
的出现,可能是
J2EE
诞生以来比较重量级的一次震撼
,规范发布至今已有半年之多,业界对
Java EE 5
的关注也变得越来越热烈,
google
一下“
java ee
”关键字,可以得到
500
多万条相关纪录,而从
Sun
网站上进行检索(
http://java.sun.com/javaee/overview/compatibility.jsp
),也可以看到专业厂商已经迅速跟进,除
Sun
公司本身外,包括全球闻名的
SAP
、金蝶
Apusic
等另三家,已经推出全面支持
Java EE 5
规范的应用服务器产品。
Java EE 5
包含
JSF 1.2
、
EJB 3.0
及
JAX-WS 2.0
等新功能,试图解决
Java
企业级应用开发的简便性、灵活性及易用性问题。在
Java EE 5
出现之前,很多开源框架(
Open Source Framework
)如雨后春笋般涌现,尝试从某种角度或某些方面去解决“委员会”规范所未能顾及的应用开发问题,如
Web
开发中的关注分离问题(
MVC
)、业务模型实现问题(
ORM
)等等。很多开源
framework
都非常出名,为人们喜爱并广泛使用,如
Struts
、
Spring
、
Hibernate
等,这些“江湖派”作品曾经一定程度上成为
Java
企业级应用开发事实上的标准。
Java EE 5
的出现,是否会改变这种状况?或者说,人们在重新选择应用框架时,是否会优先考虑全新的
Java EE 5
技术?带着这种疑问,笔者试图进行简单的技术比较,并辅于肤浅的评论,希望能够抛砖引玉、借花献佛,以娱大众。
Struts vs. JSF
|
Struts
|
JSF
|
MVC
|
支持
|
支持
|
POJO
|
|
支持
|
页面流(
Page Flow
)
|
支持
|
支持
|
UI
组件(
UI Component
)
|
|
支持
|
MVC
是模型(
Model
)、视图(
View
)、控制(
Controller
)分层的结构,通过分层来实现关注分离,减少传统开发中常见并重复的工作。
Struts
和
JSF
均支持
MVC
。
Struts
对
MVC
支持的核心是
Controller
,通过
Controller
(一个共同的入口
Servlet
)获得
HTTP
请求,将
HTTP
参数传入
ActionForm
,然后将
ActionForm
传给
Action
类
。
Struts
对
HTTP
请求只有一个事件处理
handler
,当请求过来时,由相应
Action
返回结果给前端
Controller
,并据此选择如何进行导航。
JSF
一般也采用一个前端
Controller
(有些商用
JSF
能够智能识别
JSF
请求,无需额外的
controller
),不过在
Controller
中做的工作跟
Struts Controller
截然不同,它负责触发
JSF
页面组件中的事件,用
Render
工具生成组件的展现,绑定来自
Model
的数据到组件等。可以看到,
JSF
在在控制层更灵活,在视图层支持
Render
工具的变换而生成灵活的展现,在模型层实现与框架的彻底分离,因而具有更高的灵活性。
POJO
是无格式
Java
对象(
Plain Old Java Object
)。
POJO
与
AOP
结合被广泛用于快速业务模型。
Struts
设计的初衷主要是解决视图和控制问题,并无过多关注模型的灵活性问题。
Struts
中的
ActionForm
模型必须继承自框架类,虽然可以通过定制类库提供一些帮助类实现模型与框架无关,但本质上还是紧耦合于
JSP- and HTTP-centric
方法
。
JSF
提供了对
POJO
天然的良好支持,并支持通过
RAD
工具实现快速的业务模型生成,从而具有更高的生产力。
页面导航的最大意义是帮助实现页面的可视化开发,在
UI
界面上快速定义页面流向。页面导航分静态导航和动态导航两种,静态导航是页面直接流向另一页面,动态导航是由特定动作或逻辑决定页面的流向。
Struts
和
JSF
均支持静态和动态页面导航。不过
Struts
中的导航规则是绑定到
Action
中的,那意味着可能需要对同一页面中不同的
Action
做重复性的导航规则制定,而
JSF
导航可以跟
Action
无关,可以在页面中不同组件的不同
Action
间共享相同的导航规则。
Struts
本身并不提供
UI
组件机制,而
JSF
则提供了完整的
UI
组件机制。通过
UI
组件的定制和重用,能够极大地简化开发,提升用户体验。商业化的产品则往往更进一步,提供强大易用的开发工具,实现
drag-and-drop
方式所见即所得的
Web UI
开发。
Spring vs. EJB 3.0
|
Spring
|
EJB3
|
标准(
Standard
)
|
|
是,
Java EE 5
标准组成部分
|
持久(
Persistence
)
|
JDBC, Hibernate, JDO, iBatis and JPA
(
ongoing spring 2.0
)
|
JPA
|
声明式服务(
Declarative Services
)
|
支持
|
支持
|
依赖注入(
Dependency Injection
)
|
支持
|
支持
|
集群(
Cluster
)
|
|
支持
|
Spring
框架是一个开源项目,并不是一个标准的东西。
Spring
自己定义了一套
XML
配置文件大纲以及程序接口,从长远考虑,有很大的不确定性。
Spring
的主要开发者来自
Interface21
公司(这是帮我非常敬重的人),
Interface21
靠相关咨询和服务维持,作为一个商业团体其利益取向将可以完全左右
Spring
未来的方向。相比
EJB 3
出身名门正派的标准血统并有众多主流商业厂商支持,
Spring
的非标准性将可能带来极大的风险。
Spring
框架本身不带持久实现,但它支持
JDBC, Hibernate, JDO
和
iBatis
等持久化框架。
Spring
通过使用不同的
DAO
和
Helper
类以利用
JDBC
、
Hibernate
、
iBatis
或
JDO
,所以并没有实现和最终服务提供者的隔离。简单来说,就是需要重构代码才能实现持久化框架的更换。
EJB 3.0
的持久集成在应用服务中,通过
JPA
,可以在底层更换持久实现,如将
Hibernate
更换为
Toplink
。
EJB 3.0
的持久具有更大的灵活性,并有利于厂商进行性能优化和扩展。
Spring
和
EJB3.0
都为企业应用提供运行时服务,(如:事务、安全、日志消息、配置服务)。由于这些服务都不是直接与应用的业务逻辑相关联,所以都不是由应用来自行管理。
EJB3.0
使用
Java
注释来配置声明式服务,
Spring
使用
XML
配置文件。在大多数情况下,
EJB3.0
的注释声明显得更为简单和优雅。
Spring
使用
XML
来定义属性并配置声明式服务的结果将是一个冗长而不稳定的配置文件。
依赖注入模式(
DI
)是在应用中实现松散耦合的最佳实践。
Spring
和
EJB3.0
都支持
DI
模式,但他们有着深刻的不同。
Spring
支持通用的(但复杂的)基于
XML
配置文件的依赖注入
API
。
EJB3.0
支持注入大多数服务对象(如
EJB
和上下文对象)和通过简单注释声明的
JNDI
对象。
EJB 3.0
完全支持集群。部署在服务集群中的
EJB3.0
应用将自动获得负载均衡、分布缓存、状态复制等功能。底层的集群服务隐藏在
EJB3.0
编程接口后面,屏蔽了所有的复杂性。
Spring
没有简单的利用集群的方法。
Hibernate vs. EJB 3.0
Hibernate
与
EJB 3.0
其实并没有很好的可比性,因
Hibernate
仅关注
ORM
,而
EJB 3.0
更多则更多表现为一种组件框架,其中包含
ORM
部分而已。
EJB 3.0
在设计过程中,曾经得益于
Hibernate
的作者
Gavin King
,据说
EJB 3.0 EntityBean
的设计理念完全来自于
Hibernate
。只需用将
EJB 3.0 EntityBean API
调用转换为
Hibernate API
,
Hibernate
就可以成为
EJB 3.0
中
EntityBean
的
Implementation
。
当开源
framework
已经成为习惯性势力,并给人们带来众多乐趣或疲惫感的时候,
Java EE 5
的出现会是适逢其时吗?无论如何,是继续选择开源还是拥抱
Java EE 5
?相信今天这并不是个容易的选择,或许,随着更多的厂商发布支持
Java EE 5
的产品,提供更好的工具支持,这个答案才会明朗起来。
|