1

我正在使用具有一些 Wicket 页面的应用程序，这些页面分为一些应用程序。我们正在扩展 Wicket 开发以替代其他遗留内容。目前，是否为每个工作流编写新的 Wicket 应用程序，或者我们是否应该拥有一个包含许多 URL 映射的大型应用程序，都没有明确的路径。我也没有找到任何有关此的信息。

就我们而言，我们看到以下问题：

许多 Wicket 应用程序模式：

  • 每个应用程序（工作流程）都可以轻松安装，没有太多麻烦。
  • 即使不是更耗时，您最终也会编写更多 Java 类（至少对于每个应用程序，您至少需要一些基本结构）。
  • 每个应用程序的默认 URL 都由其主页访问，因此无需进一步配置。

一大应用模式：

  • 每个工作流都需要一个页面，该页面必须映射到 Application 类中。据我所见，xml 文件中没有配置可以对此进行归档，但应该可以开发一些允许在某些 xml 文件中构造它的模式。缺点：第一次比较耗时
  • 对于进一步的补充，它应该比应用程序模式更容易一些，但考虑到工作流开发总是比初始配置大得多，它不会产生真正的不同。
  • 每个 Workflow 默认 URL 都可以通过 URL 映射访问，并且可以轻松更改，这似乎比使用 Application 方法容易一些，但也没有太大区别。

现在，我在寻找什么：

  • 基于经验的意见，也许是决定一种或另一种方式的论据。
  • 是否有来自 Apache 的任何文档或某些来源？如果是这样，一些参考将是一个很好的建议。
4

2 回答 2

2

据我了解，您仍然可以在一个 Web 存档中部署所有 Wicket 应用程序。

这样做，在我看来，你失去了将代码分成不同的 Wicket 应用程序的唯一真正优势。如果您将代码分成多个 Wicket Application类

  • 您必须考虑以相同的方式配置每个 Wicket 应用程序，并且不要忘记单个应用程序（将其包含在 web.xml 中，在 init() 方法中调用相同的设置，...）
  • 正如您自己所说的那样，您正在编写更多样板代码

配置和代码将比“单一应用程序”方法更复杂。使用单个应用程序

  • 您只需要在单个应用程序类中安装每个工作流的起始页...与新类相比，这是一行代码，而在多个应用程序应用程序中则需要几行 web.xml 配置

因此，如果您不想单独部署工作流程，我会使用单个应用程序。它使它变得容易得多。尤其是当您积累了多个工作流时，单一应用程序方法可能更容易维护。

于 2013-06-20T20:01:59.183 回答
0
  • 你可能有多少共享尾声？
  • 不同的工作流程是否有不同的性能/负载容限/可用性要求？

这些是我通常用来决定是否应该在一个应用程序中执行两件事的问题，这几乎与 Wicket 无关。

显然，许多共享代码指向单个应用程序。当然，您仍然可以根据一组共享模块使用单独的应用程序，但实际上您将花费大量时间来尝试使模块保持同步。

同样，完全不同的可用性要求可能会引导您使用单独的应用程序，因为您可能希望单独部署它们。

最困难的情况是，如果您有很多共享代码并且您仍想单独部署它们，在这种情况下，可能值得考虑使用多层方法（多个前端连接到一个公共后端）。

于 2013-06-20T13:22:33.030 回答