框架之轻量级和重量级
一:基本概念:
量级主要是看容器的依赖性所决定的
,
依赖性越小
,
越轻量
.
1
、轻量级框架
1.
定义:在
Java
应用程序开发环境中,
“
轻量级
Java”
主要是指两个东西:简化的编程模型和更具响应能力的容器。轻
量级
Java
旨在消除与传统
J2EE
API
有关的不必要的复杂性和限制。它也将缩短应用程序的部署时间,这对于支持开
发最佳实践(比如频繁单元测试)非常重要。
2.
现在比较重要的轻量级以及对终端用户的帮助:
控制反转
(IoC)
模式在这个领域有着重大的影响。
使用
IoC
,
开发人员
不需要编写复杂的代码来执行查询、处理基础架构异常或管理连接,就能够解决对象依赖性问题。这有助于简化代码、
将业务逻辑与基础架构分离,从而使应用程序更易于维护。
轻量级
Java
的另一个关键特征是,它不会强迫业务对象遵循平台特定接口。这允许开发人员在普通旧式
Java
对象
(POJO)
中实现业务逻辑
,
从而提高生产率。
与具体的类相反,当把开发的最佳实践与界面相结合时
,
这些特性也使得对代码进行单元测试容易得多。由于业务逻辑
实现在
POJO
中,
所以不再需要将对象部署到重量级容器中以在单元测试中练习它。
因此,
将对象宿主在诸如
JUnit
之
类的简单测试环境中和为快速迭代单元测试
“
模拟
”
外部依赖性就变得微不足道了。
3.
现在典型的轻量级框架:
Struts
、
Hibernate
、
Spring
、
Beehive.....
注:感觉转向轻量级技术越来越猛了,传统的重量级
EJB
也推出
EJB3.0
也基本上是以使得轻量级
Java
盛行的概念为
基础。
2
、重量级框架
dev2dev:
人们在想起应用服务器供应商时,通常把它们置于
“
重量级阵营
”
。我想您正在努力改变这种状况,对吧?换言
之,许多人认为应用程序供应商已经在实现重量级组件(比如
EJB
2.0
)上付出了很大的代价,它们不愿意轻易放弃这
些成果。
Jim:
首先,我认为没有理由放弃在
EJB
上的现有投资,因为在某些场景中它仍然是最好的技术,例如当您希望通过
RMI
远程公开业务服务时。当然,诸如
EJB
之类的开放标准在保护客户投资方面的价值也不能低估。
已经说过
,
我觉得人们经常过分强调
EJB
在应用服务器中的实际价值。尽管这一点未必对所有的应用服务器供应商都适
用,但是
BEA
只投入了相对较少的一部分开发资源来支持
J2EE
API
。我们工作最主要的目标是为宿主应用程序构建
最可靠、可伸缩和容错的内核。这些品质以及分布式事务服务、高速消息传递、遗留系统集成、高级
Web
服务、配置
管理、诊断和故障排除和高级安全性,代表了
WebLogic
Server
的真正价值,而且对总体拥有成本(
TCO
)有着巨大
的影响。幸运的是,这些附加值对基于
Spring
或
Beehive
的应用程序的相关性和适用性与采用
EJB
构建的应用程序
是一样的。虽然轻量级
Java
技术使得应用程序的开发和维护更容易,但是它们不会代替真正高端应用服务器的品质。
实际上,我们认为轻量级
Java
与
WebLogic
Server
是一致的。
dev2dev:
BEA
有没有一个轻量级
Java
策略?
BEA
实现轻量级
Java
的方法是什么?
Jim:
我们的策略是接纳所有有利于提高开发人员生产率、在市场上为部署这些技术提供最佳平台的技术。轻量级
Java
有助于降低开发成本
,WebLogic
Server
则有助于降低运营成本
,
它们是一个非常强大的组合。
3
、应用程序框架
dev2dev:
由
BEA
赞助的
Beehive
项目显然是一个轻量级
Java
组件模型。您能否谈谈关于
Beehive
的情况,以及它
在你们的整个策略中的地位?
Jim:
Beehive
是一个应用程序框架,
致力于使
J2EE
应用程序和基于
SOA
的应用程序的开发更容易,
它基于我们发布
WebLogic
Workshop
的经验。它基于
POJO
和用于配置依赖性、服务质量等的元数据提供一个编程模型。元数据以
J2SE
5.0
代码注解和外部
XML
文件的形式获得支持。存在一些用于访问
J2EE
资源、定义业务和
Web
服务以及基