JavaOne大会发布《J2EE核心模式》第二版

　　http://developer.jav

a.sun.com/developer/technica

lArticles/J2EE/J2EEevolution/

　　by Dan Malks和Deepak Alur

　　June 2003

　　在2001年的JavaOne大
模式目录中涉及了15个J2EE
遇到的典型问题及其解决方
过这些例子的学习，你可以
J2EE应用过程中被发现并提

会上，我们推出了《J2EE核心模
的设计模式。这些模式是J2EE平
案。这本书里面也列举了无数糟
改善你现有的设计。所有的这些
炼出来的。

式》，里面包含一个模式目录，该
台下软件设计师和系统架构师经常
糕的实现并对它们进行了重构，通
模式都是在我们给客户创建成功的

　　模式与交流技术问题及
其解决方案并与其他人进行
术”与“学习用J2EE技术进
方面，却几乎没有哪本书介
架构师的经验，我们觉得我

其解决方案息息相关，他们可以
交流。写《J2EE核心模式》的一
行设计”混淆起来。现存的许多
绍如何应用这些技术。基于作为
们可以填补这个空白。

让我们记录一些反复出现的问题及
个动力就是人们常把“学习J2EE技
Java书籍大都介绍J2EE技术的各个
Sun专家服务Java中心的Java系统

　　不过那已经是过去了，下面我们谈现在

　　《J2EE核心模式》第一版出版以后，
几年中，J2EE模式讨论区非常活跃，注册
j2eepatterns-feedback@sun.com收到大
重要的大型J2EE结构，也参与几个项目的
了另外的一些模式。

我们收到读者对那15个模式大量的反馈意见。过去的
会员也超过2000人。我们很高兴能从
量读者的直接反馈意见。这几年中，我们又做了几个
开发，其间我们不断地应用这些模式，同时又总结出

　　基于大家的反馈以及我们在工作中取
该书的第二版。原有的15个模式全部都进
加了有关Web服务（Web service）的内容
，那么现在一共有21个J2EE设计模式。新
抽象，你可以用来构造和理解J2EE应用。

得的经验，在2003年的JavaOne大会上，我们又推出
行了修正和更新，引进许多新的实现策略和例程，增
，覆盖了最新的J2EE1.4。我们又引进了6个新的模式
增加的6个模式主旨在于改进模式语言，提供了高度

　　模式目录

　　我们在第二版种引入了6个新的模式，每一层两个：

　　表示层模式：

　　环境对象（Context Object）

　　应用控制器（Application Controller ）

　　业务层：

　　应用服务（Application Service ）

　　业务对象（Business Object ）

　　集成层模式：

　　域存储（Domain Store）

　　Web服务代理（Web Service Broker ）

　　下面图中显示了模式目
示了各个模式之间的关系。
略以及一些新的例程。

录中的21个模式，图1、图2、图
请注意，所有的模式都已经修正

3分别显示了各层中的模式，图4显
并更新过，包括了一些新的实现策

　　图1：表示层模式

　　图2：业务层模式

　　图3：集成层模式

　　图4：各模式之间的关系

　　精选模式

　　这一部分，我们对新引进的6个模式
，包括其他模式、实现策略、例程、UML
模式"。

的一小部分进行一个简单的介绍。其他更详细的信息
框图、糟糕的实现及J2EE重构等，请参考"J2EE核心

　　虽然直到现在环境对象
中会经常用到它。环境对象
、可扩展性以及易测试性。
UML序列图以及使用这个模

（Context Object）才被记录为
（Context Object）的使用可以
下面我们介绍一下这个模式所涉
式的后果。

一个模式，但是实际上我们在工作
提高系统的的可复用性、可维护性
及的问题、解决方案、UML类图、

　　环境对象（Context Object）

　　问题

　　你想避免在相关环境之外使用与系统特定协议有关的信息。

　　一个应用程序总是要通
信息以及安全性数据等，这
务在该特定环境之外直接使
在特定环境的外部使用协议
且过于暴露了细节。每一个

过请求/响应的生命周期使用一
些系统信息总是与特定的处理环
用这些系统信息的话，那么这些
相关的API就意味着所有使用这
客户组件因而都与特定的协议紧

些系统信息，比如请求信息、配置
境有关。如果应用程序的组件或服
组件的灵活性和复用性就降低了。
些API的组件都被完全曝露了，并
紧绑定在一起。

　　解决方案

　　创建一个环境对象，以
用这个环境对象。

一种与协议无关的方式封装系统

信息，然后在整个应用程序内部使

　　如下面图5所示，把系统信息封装在
样就可以避免把应用同特定的协议绑定在
求参数，如果使用一个环境对象以一种与
和验证就会变得容易一些。而且，程序的
用考虑HTTP协议的问题。如果协议发生变
它部分不用作任何改动。

一个环境对象中，允许程序的其它部分共享访问，这
一起。比方说，HTML form中每个域都是一个HTTP请
协议无关的方式存储这些数据的话，那么数据的转换
其它部分也可以直接从环境对象中访问这些信息，不
化了，那么只用修改环境对象就行了，应用程序的其

　　图5：环境对象（Context Object）的UML类图

　　结果

　　提高了可复用性和可维护性

　　既然应用程序的接口独立于特定协议
各种各样的客户端复用。

，那么其中所定义的组件和子系统就更通用，可以被

　　提高了易测试性

　　使用环境对象模式可以
者消除了这些依赖，可以更
JUnit来进行自动测试。

帮助清除与特定的Web容器或应
容易进行测试。比如说可以使用

用服务器相关的代码。如果限制或
一些自动测试工具，例如使用

　　降低了接口变化的约束

　　原来应用程序的接口接
用接受环境对象就可以了。
更容易进行。这对于开发应

受大量的系统信息，现在使用环
这样可以降低应用程序与特定平
用程序框架非常重要，当然对于

境对象封装这些数据，应用程序只
台的耦合度，使得以后的修改可以
开发通用程序也很有价值。

　　性能的降低

　　使用环境对象模式要在对象间传递各
的些微下降与使用环境对象带来的好处，
改等等比起来，实在是微不足道。

种数据，因而会导致一定程度性能的下降。不过性能
比如应用程序组件复用性提高、应用更容易维护和修

　　我们在业务层模式中新
）。这个模式与普通的业务
代码重复，而如果把这些逻
的剧增。

增加了两个模式，其中之一就是
逻辑有关。因为如果使用Sessio
辑封装在业务对象（Business O

应用服务（Application Service
n Façades的话，就会导致
bject）的话，又会导致对象数量

　　应用服务（Application Service）

　　问题

　　你想跨越几个业务层组件和服务通过聚合来形成一个业务逻辑

　　服务门面（Service fa
不包含业务逻辑，只是对外
封装了一组相关业务操作的
序则用来实现这些用例。然
为，这样会增加依耦合性，
服务门面（Service facade
降低通用代码的复用性和可

cade），像Session Faç
提供了一个简单的、粗糙的接口
行为。用例（Use Case）用来协
而，你不应该让用例协调业务对
降低这些业务对象间的内聚力。
）上，因为业务逻辑在不同的门
维护性。

ade或者POJO Façade几乎
。业务对象（Business Object）
调这些业务对象和服务，而应用程
象（Business Object）内部的行
同样，你也不应该把业务逻辑加到
面之间潜在地复制了代码，这样会

　　解决方案

　　使用一个应用服务（Application Se

rvice）聚合各种行为来提供一个统一的服务层。

　　应用服务（Applicatio
可能封装了各种业务对象和
使用应用服务（Applicatio
组件封装成为一个高级的业

n Service）提供了一个实现业
服务。这种实现业务逻辑的方式
n Service）模式，你可以把分
务逻辑。

务逻辑的中心位置，这个业务逻辑
，可以降低业务对象间的耦合性。
散的、使用底层业务对象和服务的

　　即使你的应用程序中没有用到业务对
Application Service）模式来提供一个
Application Service）可能会包含你程
处理持久性数据的时候，可能还会包括数

象（Business Object），你也可以使用业务服务（
统一的业务逻辑实现层。这种情况下，应用服务（
序中实现不同服务必需的所有中间业务逻辑，如果要
据访问对象（Data Access Object，DAO）。

　　图6：应用服务（Application Service）