【IT168 技术文档】
BEA WebLogic Portal 8.1的发布引入了大量新技术。其中包括：包含注释的Java页面流、Java控件以及用来支持它的新IDE。程序包中也包含有在线教程，用于演示如何才能最有效地利用这些新技术。
我们使用BEA WebLogic Workshop、Java页面流和Java控件创建了一个大型门户应用程序，它由大约200个包含五个不同功能区域的页面组成。在开始之前，我们对这项技术进行一下评估。我们旨在创建一种架构，以便使得我们能够基于以下软件工程原理进行测试驱动开发：
松散耦合
每一层具有清晰职责的分层架构
通过简单的小型类而实现的可维护代码
可单元测试的代码
持续集成
BEA参考文档并未明确介绍如何在BEA Portal应用程序中实现这些特征。这就意味着我们必须找到一种方式将从传统软件工程所获得的这些优点并入新的BEA技术中。在本文中，我们将通过Java页面流和Java控件架构来讨论实现这些优点的方式。
扩展后的页面流架构
在架构中各组件之间创建松散耦合的主要原因是为了确保在引入更改时，除要更改的组件自身外，尽可能不对其他组件造成影响。图1展示了基本的Java页面流架构。 
图1 基本的分层架构
从图1中可看出，此架构使用了清晰的分层方法。然而，除了最简单的项目，此基础架构对所有项目来说都太简单了。典型的Web应用程序用例由三个主要部分组成：
准备一个包含一些预先填充的数据和一个表单的界面，并将其呈现给用户
用户将数据输入表单中
数据经认证并发送回后端系统
通常必须添加负责将数据从后端系统转换为可呈现表单的附加代码，以执行复杂的认证并将数据转换回后端系统的格式。这意味着要在应用程序中引入一个新层。我们选择将此层称为Action Delegate（动作委托）层（参见图2）。
图2 扩展后的分层架构
Action Delegate层负责编排应用程序的逻辑。这意味着我们将编排工作从页面流控制器（Page Flow Controller，PFC）中的单个动作方法委托给ActionDelegate类中的对应方法。我们的经验是：在正常情况下，对每个PFC使用一个ActionDelegate类是一种比较好的做法。这为我们提供了良好的责任分割。PFC的动作方法现在成了外观。它们唯一的用途是将其工作委托给ActionDelegate，并基于ActionDelegate的返回值跳转到适当的jsp/嵌套页面流。
如果PFC有许多动作方法，则ActionDelegate层让我们有可能使用来自一个PFC的多个ActionDelegate以对逻辑连接起来的功能进行分组，并保持小型且可维护的ActionDelegate类。此处要注意的一点是，如果发现PFC中有大量的动作方法，则可以考虑将其重构为一个或多个嵌套页面流。
另一种缩小PFC的方式是放弃使用用于创建表单bean的内置功能。由Wrokshop Wizard所创建的表单bean被实现为对应PFC中的静态内部类。此外，完全可以创建自己的表单Bean并使用它们。这样会由于使用了较少的代码复制而得到更清晰的代码。
