Wicket还是Playframework？

Question

我对Java开发完全陌生，我想选择一个好的Java框架来学习。我发现了一些关于Apache框架和花架的很好的回音。我决定选其中一个，但我需要选择

那么，应该选择什么，为什么呢？

编辑

我的要求：

• 我有很好的开发Django的经验，所以类似的框架会很好，
• 我需要一个可以与其他主流Java (库、工具..etc)交互的框架，这样我就可以利用Java真正提供的功能。

Answer 1

Wicket和Play是两种非常不同的框架类型。

Play是一个MVC框架，您可能会对来自Django的开发感到熟悉。像Django一样，它提供的不仅仅是web比特，它还提供了一个基于JPA的ORM框架、脚手架工具以及更多的工具(我对它没有实际经验)。他们的网站上有一个很棒的教程，你可能会看到Django的相似之处。

Wicket是一个面向组件的框架(如JSF和Tapestry)，主要关注面向对象的设计。它本身也是MVC的，但是页面通常是通过组合自包含和可重用的组件(View和Controller，可插拔模型)来构建的。这些组件可以通过标准继承和组合进行扩展，并且标记与代码非常清晰地分离，并且易于修改。

Wicket可以自动管理事件回调和状态，因此您根本不必考虑urls，不管您的页面有多复杂。一个可点击按钮的快速示例，当它被单击时会消失(非常有用)：

  // In a page constructor
  add(new Link("link") {
        public void onClick() {
          setVisible(false);
        }
    });

我想强调的是，您不必使用服务器端状态，如果您想使用Wicket作为“正常”MVC框架(当然，获得漂亮的urls很容易)，这是完全可能的。

Wicket项目只关注核心web框架，没有额外的“细节”，比如特殊的ORM支持或脚手架。我个人同意Wicket项目的理念，但是对于新的开发人员来说，做一些“简单”的事情，比如可排序和可分页的表，可能有点让人望而生畏，因为预构建的组件有点缺乏。Wicket的学习和效率曲线可能有点陡峭，但好处是，一旦您制作了适合您需要的组件(和“行为”--更长的故事)，它们就非常可重用。

虽然我个人喜欢Wicket，但我有一个预感，你可能会是最好的发挥。您的问题表明您希望有一个访问Java库的"Django“，在这种情况下，我认为Play (或其他一些Java )是安全的选择。另一方面，也许你一直在使用Django，因为你不知道Wicket有多强大。如果你能提供更多关于你的项目的信息，我们就能给出一个更有条件的答复。

作为一个边节点:由于Play不是很主流(至少目前是这样)，我也会考虑砂砾，它有强大的商业支持，甚至更多的开箱即用的模块。

Answer 2

玩!是为来自Python和PHP等脚本语言的开发人员设计的。它提供自己的构建系统和管理脚本，有点像Rails或Django。现有的构建工具和基础设施(如Java中常用的Maven存储库)将无法与Play很好地集成。

对于来自Java桌面开发的开发人员来说，Wicket将更加舒适。它没有提供特殊的工具，所以如果您有偏好，那么集成到特定的构建工具中就更容易了(而且有许多构建工具提供了诸如Java生态系统中可用的自动依赖检索之类的功能)。

因此，这两种选择之间有相当大的区别:)如果您能够确定哪种经验对您最有好处，那么您的决定就应该非常明确。

Answer 3

如果您的系统只用于Web层，请播放！框架非常适合。But，如果您的数据模型不只是用于web，可能是exported as REST by Spring with CXF，并且由GWT或其他web服务使用，并且您希望确保web层的一致状态，Wicket (使用Spring/hibernate)是一个很好的选择。

我对玩感觉不太好的东西！是缓存机制。您必须手动命名/插入/检索/无效/清除缓存。这将使整个体系结构容易出错。虽然wicket使用spring/JPA(Hibernate)/ehcache(或其他提供程序)，但您可以为上层(web/REST.)定义一致的缓存/数据层，这不会造成状态不一致。

wicket的另一个优势是它内置了Java支持的AJAX。虽然这些AJAX的状态是在服务器端维护的(可能有些迟钝)，但是如果您不想学习JavaScript，您仍然可以构建一个“不那么糟糕”的AJAX页面。

使用Play！，如果您不知道JS，也不想学习它，也不想操纵累赘的空间，那么您只能构建一个“普通”站点。OTOH，如果你精通JS / jQuery，你可以选择玩！