Go-ForIt 记事：eXtreme DragonSlayers 专题报告，第 8 部分: 陷入多级显示漩涡

核心提示： 投标被处理并且出现一个提示成功的屏幕，确认投标已被输入，Go-ForIt 记事：eXtreme DragonSlayers 专题报告，第 8 部分: 陷入多级显示漩涡(2)，当 PA 单击 OK时， 显示差事列表，我们考虑了一些最常用的高速缓存信息，以便在应用程序内部轻松访问信息的方法，且被投标

投标被处理并且出现一个提示成功的屏幕，确认投标已被输入。当 PA 单击 OK时， 显示差事列表，且被投标差事显示出新状态。

难题

我们在为上述情景设计应用时遇到了几个难题。我们希望尽量遵守我们的 Go-ForIt 项目设计目标，特别是

用户界面（UI）的静态部分用 HTML 实现。

用户界面的动态部分用 JavaServer Pages（JSP）页面实现。

所有的用户行为都由 servlet 处理，它先调用相应的会话 bean 的适当方法，然后调用适当的 JSP 页面向用户返回行为结果。

当选择了 View Errands 选项时，我们不知道可能会显示多少差事。可能是零，也可能是数百。 这是一个有趣的设计问题，但我们不打算在本文中讨论它。（呜，听上去象是另一篇文章......）

选择一个差事向 PA 显示一个页面，页面上带有关于该差事的详细信息和三个选项：cancel、reject 或 bid。不管他们选择哪个选项，最终都会再次显示差事列表。我们不希望每次都从数据库检索列表，所以我们希望将这些信息保存在某个地方一直到需要时。如果 PA 对差事进行投标或拒绝了它，我们不得不跟踪差事的新状态，并且在每次显示差事列表时都反映每个差事的当前状态。所以，我们不仅需要存储列表以便快速检索，我们还必须不断地更新它。这就是我们在本文中处理的问题。

当面对设计问题时，获得十个备用方案的最好方法是与十个设计师进行交谈。我们的项目也一样，但由于我们都相处得非常好，不管什么时候出现什么错误我们都不会责怪任何人，我们也进行过一些有趣的讨论，讨论出了几个合理的备用方案。我们考虑了一些最常用的高速缓存信息，以便在应用程序内部轻松访问信息的方法，每种方法自然都有自己的优点和缺点。