系列文章：使 Oracle Application Development Framework 和 Subversion 适应企业需求

第 5 部分：Oracle ADF 应用程序架构

作者：Chris Muir

这是由五部分组成的系列文章“使 Oracle ADF 开发和 Subversion 适应企业需求”的第 5 部分。内容涵盖：

• Oracle JDeveloper 11g 应用程序架构

• Oracle ADF 库和 Resource Palette

• 最终完成 Oracle ADF 库 CR

• 其他一些规则

Oracle JDeveloper 11g 应用程序架构

本文到目前为止，我们一直考虑的都是由两个项目组成的相对简单的“单个”Oracle ADF 应用程序。这采用的是 Oracle JDeveloper 10.1.3 应用程序使用的应用程序架构的模型。这种方法有一些问题：

• 生成的应用程序可能很大；将应用程序分成逻辑块时必须小心谨慎。

• Oracle ADF 应用程序，就其本质而言，有一些中央配置文件来驱动应用程序的操作。因为不同的团队成员处理应用程序的不同部分，他们经常需要更改中央配置文件两个或多个开发人员要同时等待更改主配置文件的概率很高。

• 初级程序员很可能不清楚他们的操作对整个代码库会有什么影响，因此无意中修改了代码中不应该更改的地方。

• 该架构原来不支持对人力进行明确的分工。

在 Oracle JDeveloper 11g 中，可以有一个组合主 Oracle ADF 应用程序工作区，通过 Oracle ADF 库工具加载和使用众多其他应用程序。这些其他应用程序由一个或多个绑定任务流 (BTF)、声明式组件或页面模板组成。目的是每个组件单独制作（很可能是由不同的团队成员进行），然后由主 Oracle ADF 应用程序将它们组合在一起。

这种架构有许多优点：

• 主要优点是这种架构允许组织有一个或多个主组合 Oracle ADF 应用程序，根据迷你应用程序的适用性而重用它们。

• 各团队成员可以承担其中一个迷你应用程序的工作，因此有明确的分工。

• 这样，初级程序员就很难无意更改系统的其他部分所依赖的关键文件。

尽管这些优点非常明显，但也存在更大的挑战：

• 当创建一个或多个主 Oracle ADF 应用程序时，跟踪它们依赖于哪些迷你应用程序将变得非常重要。

• 哪里可以找到主 Oracle ADF 应用程序的迷你应用程序？

• 从本文的角度来看，非常重要的一点是，如何处理这些迷你应用程序的变更控制？当提出更改请求时，该请求是应用于主 Oracle ADF 应用程序、主 Oracle ADF 应用程序使用的迷你应用程序，还是同时应用于这两者？

以下几部分概述了对以上挑战的可能解决方案。这些部分将引导读者评估所概述的解决方案，以确保该方案适合读者想达到的目的。读者应注意到，库依赖性管理的问题是 Java 开发和其他提供强代码重用工具的语言中的一个复杂领域。在 Java 领域中，提供了像 Ant-Ivy 和 Maven 这样的工具来帮助缓解和控制这项负担，强烈建议读者研究一下这些解决方案。本文所提供的解决方案可能过于简单，它只是演示示例中的问题，启发读者思考。该解决方案本身可能不适合大型开发。

Oracle ADF 库和 Resource Palette

Oracle JDeveloper 的 Oracle ADF 库和 Resource Palette 工具提供了在主 oracle ADF 应用程序中加载和重用一个或多个迷你 Oracle ADF 应用程序的功能。每个迷你应用程序被压缩成一个 Oracle ADF 库，Resource Palette 则公开迷你应用程序以便加载到主应用程序。

创建和维护迷你应用程序

在考虑我们的原始 Beanz 应用程序时，可以将其视为一个主 Oracle ADF 应用程序，它需要利用包含名为 MiniBean 的绑定任务流的迷你应用程序。在主 Beanz 应用程序中包含 MiniBean 是在 CR005 中提出的。

我们将 CR006 分配给某个开发人员去做。作为一个全新的迷你应用程序，开发人员将创建关联的 Oracle JDeveloper 应用程序工作区和多种其他设计时构件以满足要求：

有一个重要的问题，就是在我们的 SVN 信息库中，这个迷你应用程序放在哪儿？我们的信息库只存储原始 Beanz 应用程序：

解决办法就是在 MiniBean 应用程序自己的树中签入 MiniBean 应用程序。因为我们未来可能有多个（即使不是数百个）迷你应用程序，因此还必须创建高级别的子目录，以便在逻辑上将这些迷你应用程序与主应用程序分隔开来。结果如下：

注意在 ADFMiniApplications/MiniBean 树下使用了 tags 和 trunk 结构，但缺少 branches。稍后再详细讨论这个问题。

创建 Oracle ADF 库

要将 MiniBean 应用程序加载到 Beanz 主应用程序，需要创建一个 Oracle ADF 库。这是通过在 MiniBean 应用程序的 ViewController 项目上创建 Oracle ADF 库部署配置文件来完成的。打开 ViewController Project Properties → Deployment 节点：

默认情况下，WAR 文件部署配置文件已经存在。如果迷你应用程序在本地开发人员的集成 Oracle WebLogic Server 上独立运行和/或测试，则将维持现状。

选择 New 按钮将显示 Create Deployment Profile 对话框，可以在其中选择和输入以下信息：

注意 Oracle ADF 库存档类型，更重要的是注意要生成的 JAR 文件名。JAR 文件名明确地指出了是为哪个 CR 创建的迷你应用程序。

在此接受所有更改，关闭窗口，右键单击 ViewController，然后使用刚创建的 Oracle ADF 库选项进行部署，接受弹出的 Deploy 对话框中的默认值：

如结果日志窗口中所示，Oracle ADF 库 JAR 文件已写入文件系统：

不应将 JAR 文件签入 SVN（因为总是可以重新生成它），但必须将对 ViewController 项目文件的更改签回信息库，这一点至关重要。

开发人员自信工作已经完成之后，代码就可以用在别处，在 SVN 信息库中，MiniBean/trunk 应被标记上相应的 CR 号，从而生成以下信息库配置：

从 Resource Palette 加载 Oracle ADF 库

此时，我们要将 Oracle ADF 库加载到主 Oracle ADF 应用程序中。从变更控制的角度来看，这是对现有应用程序的更改，因此被分配将 Oracle ADF 库加载到主 Beanz 应用程序的开发人员会将其加载到 Beanz 应用程序的 trunk 中。这意味着开发人员应从 SVN 信息库中的 Beanz\trunk 签出工作副本。

Oracle JDeveloper 11g 提供了 Resource Palette（可通过 View 菜单访问），作为一种将迷你应用程序加载到主应用程序中的简单方法：

Resource Palette 的 New Connection 菜单允许您创建到存储 Oracle ADF 库的任何位置的命名文件系统连接：

在 Create File System Connection 对话框中，输入该连接的名称和 Oracle ADF 库的位置：

此任务会产生一个问题。因为由单独的开发人员将 MiniBean Oracle ADF 库 JAR 加载到主 Beanz 应用程序中，该开发人员应从哪里获取这个库呢？一种解决办法是将 MiniBean 应用程序签出到该开发人员的本地计算机，部署 Oracle ADF 库 JAR，然后连接到该 JAR 所在的目录。然而，这种解决办法不能随着更多迷你应用程序的创建而扩展。每次需要更改主 Oracle ADF 应用程序时，这种解决方法都要求负责的开发人员将迷你应用程序从 SVN 信息库签出到本地 PC 上前一个开发人员签出的位置。

另一种办法则简单得多，即创建所有开发人员共享的中央网络位置。将共享的 Oracle ADF 库放在该处，并将 Resource Palette 配置成使用该位置。在 Microsoft Windows 下，这可能是一个命名的网络驱动器，比如说 J:驱动器（J 表示 Java）。

（在 Oracle JDeveloper 11g PS1 build 5536 中，由于软件中的一个错误，目前对硬编码 Microsoft Windows 驱动器之外的网络路径的支持很有限。理想情况下将使用网络路径，因为这不需要 Microsoft Windows 开发人员使用宝贵的映射网络驱动器。建议读者检查一下自己所用的 Oracle JDeveloper 版本是否摆脱了这种限制。）

若使用此办法，当 MiniBean 开发人员完成工作并进行标记后，该开发人员还应将一个 Oracle ADF 库的副本放在共享网络驱动器中。

现在，在 Resource Palette 中创建文件系统连接时，我们可以指定驱动器位置：

生成的 JAR 文件显示在 Resource Palette 中：

然后可以通过选择主 Oracle ADF 应用程序的 ViewController 项目，接着在 Resource Palette 中右键单击要添加的 JAR，然后选择 Add to Project 选项，来将此文件添加到主 Oracle ADF 应用程序中。将显示一个确认对话框，请在其中选择 ADF Library 按钮。最后，您将在 Log 窗口中看到以下确认信息：

此外，从 Project Properties 窗口显示 ViewController 的 Libraries and Classpaths 属性，可以揭示所附加的 Oracle ADF 库：

Edit 按钮可显示加载的 JAR：

特别要注意，Oracle ADF 库特性要重用共享网络位置。因此，所有开发人员应按约定在其本地 PC 中配置 J: 驱动器，这一点至关重要。

最终完成 Oracle ADF 库 CR

修改主 Oracle ADF 应用程序的开发人员完成工作（包括集成 MiniBean 应用程序）之后，根据本文前面各部分所述，该开发人员应从 trunk 分支创建一个如 tags\CR005 的关联 tags 项，并且，如果应用程序已准备好进行测试，请将该应用程序迁移至测试环境，并将其放在 branches\test\CR005 分支中。

此时，我们将讨论 MiniBean 应用程序在 SVN 信息库中没有 branches 树的原因。由于 MiniBean 应用程序本身并未部署到应用服务器，而是组合在部署到应用服务器的主应用程序中，因此没有必要跟踪 MiniBean 应用程序升至哪个环境，因为会对主应用程序进行这种跟踪。此外，因为 MiniBean 应用程序本身可以用于一个或多个主应用程序，对于不同的主应用程序，它可能实际上到达了不同的环境；因此很难维护 branches 环境。

一些最终规则

在本部分的结束部分，需要重点强调一些规则。

Oracle ADF 库文件名中的 CR 号会告诉您哪个 CR 启动了创建新版本公共 Oracle ADF 库的工作。然而，后来具有不同 CR 的应用程序可能重用先前 CR 的 Oracle ADF 库。规则如下：

• 对于新应用程序：

  • 如果新应用程序不需要公共 Oracle ADF 库中的新功能，该应用程序可以与公共 Oracle ADF 库的一个先前 CR 号相关联。这可以通过将特定 CR 号显式附加至 J: 驱动器中的 Oracle ADF 库来实现。

  • 或者，如果新应用程序因为其功能不完整而需要新版本的公共 Oracle ADF 库，则应生成具有当前 CR 号的新 Oracle ADF 库 JAR，并将其放在 J: 驱动器上。

• 对于依赖于 Oracle ADF 库 JAR 的先前 CR 号版本的旧应用程序，请勿随意升级至更新的 Oracle ADF 库 JAR CR 号，除非您已进行过回归测试。

• 因为以上这点原因，不要假定较高的 CR 号就一定意味着更新版本的 Oracle ADF 库 JAR；CR 可能在工作中被打乱顺序。您将需要一些其他机制来设法确定哪个是最新版本，例如，Oracle ADF 库 JAR 名中包含的递增版本号或者更高级的构件版本和相关性管理工具，如 Maven。

• 如果 J: 驱动器上带特定 CR 号的 Oracle ADF 库 JAR 就是开发人员正在使用的 JAR，那么他们可以覆盖它。但开发人员绝不应覆盖 J: 驱动器上先前的 Oracle ADF 库 CR 号，除非有非常充分的理由！覆盖先前的 Oracle ADF 库 CR 号可能会中断现有应用程序。

总结

在这个由五部分组成的系列文章的最后一部分，我们研究了更广泛的 ADF 架构问题，尤其是 ADF 库以及这些库如何适应整体 Subversion 工作流。

返回系列目录