框架之轻量级和重量级

一：基本概念：

量级主要是看容器的依赖性所决定的

,

依赖性越小

,

越轻量

.

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

服务以及基