Apache Wicket的缺点是什么？[已关闭]

Wicket需要一些非常可靠的编码实践。例如，如果将 IModel 存储在组件中，但不将其用作组件的模型，则它不会自动分离，并且可能会放大会话大小。这种管理不是大多数Java用户习惯的。

检票口处于活动状态并经常更新。这很好，但是每次我更新到新版本时，我都意识到我需要做大量的重构才能转向更好的编码实践（1.4引入泛型，1.4.x引入configure（），1.5有一些不同的资源策略）。同样，所有这些都是很好的更新，并推动你走向更好的代码，但我羡慕人们现在来到Wicket，而不是两年前:)

结合上述两者，我觉得一旦你超越了基本功能集，Wicket就会假设一些真正的编程技能。如果你是一个优秀的开发人员，你会喜欢Wicket为你做的事情（代码在JavaDoc中有很好的文档记录）。如果你是一个初学者，你可能会随着你的深入而感到沮丧。

此外，虽然它在Google App Engine上“工作”，但我发现有几个问题阻止它在那种环境中舒适地工作。这是另一个讨论。

我的免责声明是我没有使用其他任何东西，所以也许其他框架更糟。

在现实世界中，Wicket的开发速度非常慢。如果您没有像装配线上的工厂工人那样使用的预制组件，那么生产力就会停止，直到您可以制造新的面板。代码复杂性增加，很难读取代码，因为您有效地将必须编写的代码行数增加了一倍。你一直在寻找如何在互联网和书籍中做琐碎的事情。例如，一个简单的重置按钮是HTML的一行，但在Wicket中，它需要谷歌搜索如何做到这一点。它使简单的事情变得困难，而困难的事情变得不可能。

我还没有看到一个用Wicket构建的真正复杂的UI。只有由预制组件组成的简单UI才能使用Wicket。我见过的用Wicket构建的每个UI如果没有在Wicket中完成，都可以有一个更干净的代码库，并且通过删除Wicket可以更好地扩展。Wicket也没有像漂亮的UI小部件那样给你买任何东西。即使是 Wicket 的 jQuery UI 实现也不如直接使用 jQuery UI。

在我的工作中阅读了数万行Wicket代码之后，我可以说Wicket代码基本上是意大利面条代码。如果你喜欢ulgy，不优雅，冗长，带有泛型和匿名内部类的代码，那么Wicket就是你的东西。线路噪声量非常高。因此，代码库变得不那么可维护。如果您使用有缺陷的 Wicket AJAX 实现，则尤其如此。