下载 Oracle JDeveloper

标签 adf, java, 全部

从设计到实践全面了解 Oracle ADF 应用程序 作者：Chris Muir 和 Penny Cookson

第 1 章 — 我的包裹在哪里？

2008 年 5 月发表

可怜的 Betty 在流泪。然而另一个客户却打来电话，向她大喊大叫，要求知道前一天晚上的包裹在哪里。我们的老板很清楚 ACME Parcels 容易丢失货物，而我们可怜的呼叫中心（即，Betty）正在寻找解决方案。

或许很愚蠢，听到老板第 n 次描述问题，您建议在 Oracle JDeveloper 11g 的 Oracle 应用开发框架 (ADF) 中构建一个 Web 应用程序以允许客户从公司的基础 Oracle 数据库中检索其包裹的状态并不很难。

我们的老板立即同意并希望我们坐下来与他一同讨论细节问题。

故事板

大多数编程人员喜欢埋头编写代码来解决任何问题。通过以往的项目灾难，我们已经获得了经验，故事板是很棒的 Web 页面设计方法。

电影业使用故事板的方法在实拍之前对电影的所有场景进行大概说明。这不仅包括摄影机镜头如何对着照明角度摇动，还包括演员的移动位置，等等。这一切都是为了实现戏剧效果，但是要比拍摄实际的场面便宜得多。

故事板也是用于 Web 页面设计的理想方法。只需与用户和一个白板进行交流，通过一个打开的对话框，让他们在白板上描述其系统，以文本形式显示他们想要的屏幕、字段、交互，等等。在空白区域可以任意添加批注，描述这些屏幕将做什么。

在与老板在白板前进行交谈并在白板上大概写下注释后，我们提出了以下解决方案：

故事板还揭示了我们系统的一些有趣事实：

• 由于数据库表中存在重复数据，因此结果区可以显示多个结果。这并不是理想结果，但是我们将进行处理，具体做法是如果返回多个记录则隐藏结果数据以保护隐私。
• 收件人的姓名以大写形式存储在数据库中，但是我们不希望对搜索进行如此限制，因此我们将为用户转换字符串数据。还有一个问题是，由于旧的运货单编号格式标准，有时客户按照旧标准在运货单编号中使用连字符。进行查询之前，我们将需要删除这些连字符。

MoSCoW 优先级排序方法

需求是需要技巧的。根据经验，我们知道老板喜欢额外增加需求，尽管这些需求并不一定需要，但是“最好具备”。作为有经验的编程人员，我们知道有些需求实现起来并不繁琐，但是有些需求则需要花费数周的时间，而且直到您开始实现才会发现这一点。

1. M — 必不可少
2. S — 应当尽可能具备
3. C — 可以具备（如果不影响别的内容）
4. W — 现在没有此需求，但将来可能具备

1. 必不可少

最初，我们只需要搜索字段和搜索结果。我们的老板意识到，由于我们仍然可能不断收到关于包裹运输的电话查询，因此我们可以将此工具提供给 ACME Parcels 呼叫中心员工，他们不需要接受条款和条件也不需要将自身标识为包裹收件人或发件人。

反过来，我们的员工将接受培训，以正确的格式（大写并且运货单编号无连字符）填写搜索字段，这样就不必将数据转化为大写也不必在该阶段修正运货单编号。但是，务必确保填写了所有搜索字段，然后再执行查询。

最后，如果结果显示多条记录，但向我们的员工显示多个结果也不必考虑隐私问题。

2. 应该尽可能具备

当我们在互联网上提供该搜索工具时，我们认为必须强制用户接受隐私条款和条件然后才能执行搜索。上次有客户投诉说，通过互联网能够在我们的系统上搜索到她的详细信息。因此，这次我们将保护自己，具体做法是，添加条款和条件来强制用户接受或拒绝其代表包裹的发件人或收件人。

因此，必须在数据库的一个审计表中存储用户的接受/拒绝选择以及用户的 IP 地址，这样我们就可以跟踪谁使用了该工具。

如果我们在将系统发布到互联网上，隐私会成为一个问题，因此如果该搜索工具返回多条记录，则不会显示任何结果，而是要求客户给我们致电。

对于互联网，还必须将字符串数据转换成大写并删除运货单中的连字符（如果有的话）。

3. 可以具备（如果不影响别的内容）

将该解决方案应用到 Web 上后，最好可以跟踪系统的采用率以及客户查找结果的成功率。如果有时间，我们将在该工具中内置相应功能，以审计搜索条件以及返回的记录数并将它们存储在数据库中。这样，我们以后可以查看进行的查询次数、输入的搜索参数、查询是否失败，以及我们是否可以就此进行相应更改以使系统更加易于使用。

4. 现在没有此需求，但将来可能具备

我们的老板特别想知道关于恶意访问的处理：如果有人使用该工具搜索其不应该看到的结果怎么办？我们认为可以在该工具中内置相应的功能，从而阻止最近一小时内进行了三次查询但未找到任何结果的 IP 地址。但是，此时由于我们并不希望出现任何恶意访问，因此该特性将留待以后实现。

总结我们收集的需求，一个与新开发有关的问题是知道从何处着手。当您面前摆着一堆需求时，很难知道应首先关注哪一个。我们真正需要的是一个分而治之的方法，将整个问题分解成可解决的独立单元。利用我们新近采用的故事板和 MoSCoW 方法（如上所述），我们可以看到对需求进行了细致分类，我们可以每次关注一个类别。

数据模型

当我们开始考虑第一个“必须具备”的需求（即，能够搜索包裹的状态）时，我们可以使用 Oracle JDeveloper 11g在 Oracle ADF 框架中将解决方案进一步分解为可解决的包裹（并非故意使用双关语)。

我们知道，使用 Oracle ADF 时，我们让 Oracle ADF 业务组件从数据库中检索数据，让 Oracle ADF Faces RC 在 Web 页面中显示数据。由于我们首先需要搜索数据并获得数据，因此我们应该首先关注我们的 Oracle ADF 业务组件解决方案。

考虑 ADF BC 视图对象时，我们知道它针对数据库执行 SQL 查询以获取数据。但是，数据源自何处？我们在本文中使用的表什么样？

在我们虚构的 ACME Parcels 中，Oracle 数据库包含下面的表：

CREATE TABLE parcels (
lodged_with       VARCHAR2(4)   NOT NULL
,rec_first_name   VARCHAR2(100) NOT NULL
,rec_last_name    VARCHAR2(100) NOT NULL
,waybill_number   VARCHAR2(10)  NOT NULL
,sender           VARCHAR2(100) NOT NULL
,location         VARCHAR2(100) NOT NULL
,status           VARCHAR2(9)   NOT NULL
,last_update      DATE          NOT NULL
,CONSTRAINT parcel_lodge_fk
 FOREIGN KEY (lodged_with) REFERENCES orgs(id));

（注意，最后一条记录的运货单编号在后来的递送中被重用。）

这里我们有意选择了一个简单的模型，以便演示 Oracle JDeveloper 方法。在实际情况中，我们希望其中的某些列是其他表的外键。

总结

在本章中，我们了解了如何使用故事板确定需求，然后如何使用 MoSCoW 方法设置这些需求的优先级。在下一章中，将介绍 Oracle JDeveloper 中基本搜索屏幕的开发。