3

我有以下问题。我们有一个应用程序，它基本上是一组控制与用户交互的 JSP 和操作类。这些操作设置了页面正确显示所需的一些参数。系统中的 url 总是包含事件的名称，它定义了我们接下来应该去哪个页面。

现在，几乎每个页面都有一个取消按钮，应该指向上一页。从一开始，每个取消按钮的 url 都被严格定义，但最终，随着系统变得越来越大，为这个按钮编写逻辑以使其准确地指向上一页变得非常困难。

例如，假设我们有三个页面，A、B 和 C。页面 A 有一个指向页面 B 的链接，而 B 有一个指向 C 的链接。因此 C 有一个连到 B 的 url（并且它还包含要在 B) 上显示的实体的键。但是，假设页面 A 被修改，现在在 C 上也有一个链接。现在我们需要检查从那里来的 C 页面并适当地设置 URL，逻辑变得非常复杂。

因此，我向我的团队提出了以下解决方案。用户会话应该包含一个称为 CancelStack 的特殊对象。导致页面的每个操作都应将其 url 推送到堆栈中（包含事件和一些所需的附加数据）。在每个页面上，取消按钮现在应该有一个指向特殊事件的 url，称为 cancelStack。

cancelStack 操作的作用是：

  • 从会话中检索取消堆栈。
  • 弹出最后一个 url，不要使用它。
  • 再次弹出 url 并重定向到该 URL。

为什么我们不使用就检索最后一个 url？假设我们有页面 A 和 B，A 通向 B。A 的操作将其 url 放在堆栈中，这应该是 B 页面的取消 url。现在，B 的操作将它的 url 放在堆栈中。因此我不使用弹出它，然后弹出第一个url，重定向到A动作，这个动作再次将A url添加到堆栈中（因此堆栈大小仅减少1，而不是2）。

这似乎是一个很好的方案，但是堆栈的顶部元素在没有使用的情况下弹出似乎很奇怪。因此我有一个问题。是否有任何设计模式可以在会话中存储 URL 序列以便正确组织取消按钮？

4

1 回答 1

1

你的所作所为在我看来是合理的。老实说，我现在想不出解决您的问题的设计模式，但我认为如果除此之外您cancelStack还保留对你会摆脱那些让你烦恼的多余的东西。 否则你只是顶部的。 例如在你的例子中： currentURLcurrentURLpop
popcancelStack

假设我们有页面 A 和 B，A 通向 B...

currentUrl是 A。A 的动作不是取消，所以currentUrlieA被推送到cancelStack. 然后它是动作，B并且currentURL是B但动作是取消，所以B不放在堆栈中。所以顶部cancelStack是A（currentUrl而是B）。因此，如果您检索（不需要额外pop的）cancelStackApop

于 2012-07-02T10:12:09.753 回答