java Wicket 还是 Playframework？

Wicket or Playframework?

提问by wassimans

I'm totally new to Java web development and I would like to choose a good Java web framework to learn. I've found some really good echoes regarding the Apache Wicket frameworkand the Playframework. I decided to go for one of 'em; but I need to choose ;-)

我对 Java Web 开发完全陌生，我想选择一个好的 Java Web 框架来学习。我发现了一些关于Apache Wicket 框架和Playframework 的非常好的回应。我决定选择其中之一；但我需要选择;-)

So, what to choose and why?

那么，选择什么，为什么？

EDIT

编辑

My requirements:

我的要求：

• I had a good experience developing with Django, so a similar framework would be great,
• I need a framework that can interact with other mainstream Java goodies (libraries, tools ..etc) so I can take advantage of what Java does really offer.

• 我有很好的 Django 开发经验，所以类似的框架会很棒，
• 我需要一个可以与其他主流 Java 产品（库、工具等）交互的框架，以便我可以利用 Java 真正提供的功能。

回答by DaGGeRRz

Wicket and Play are two very different types of frameworks.

Wicket 和 Play 是两种截然不同的框架类型。

Play is a MVC framework which you probably will feel familiar with coming from Django. Like Django, it offers more than just the web bits and provides a JPA based ORM framework, scaffolding tools and probably a lot more (I have no practical experience with it). They have a great tutorial on their site, and you'll probably see the Django similarities there.

Play 是一个 MVC 框架，你可能会觉得它来自 Django。与 Django 一样，它提供的不仅仅是 Web 位，还提供基于 JPA 的 ORM 框架、脚手架工具以及更多（我没有实际经验）。他们的网站上有一个很棒的教程，您可能会在那里看到 Django 的相似之处。

Wicket is a component oriented framework (like JSF and Tapestry) and focuses heavily on object oriented design. It's also MVC, per se, but pages are usually built by composing self-contained and reusable components (View and Controller, pluggable Models). These components can be extended by standard inheritance and composition and markup is very cleanly separated from code and easily modified.

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

Wicket can manage event callbacks and state automatically, so that you don't haveto think urls at all, no matter how complex your page is. A quick example for a clickable button that goes a away when it's clicked (very useful):

Wicket 可以自动管理事件回调和状态，因此无论您的页面多么复杂，您都完全不必考虑 url。单击按钮时会消失的可点击按钮的快速示例（非常有用）：

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

I want to emphasize that you don't have to use server-side state, and that it's quite possible to use Wicket as a "normal" MVC framework if you want to (and yes, it's easy to get pretty urls).

我想强调的是，您不必使用服务器端状态，并且如果您愿意，很可能将 Wicket 用作“普通”MVC 框架（是的，很容易获得漂亮的 url）。

The Wicket project focuses only on the core web framework and there are no extra "niceties" such as special ORM support or scaffolding. I personally agree with the Wicket project's philosophy here, but for new developers coming to the framework, doing "simple" stuff such as a sortable and pageable table can be a bit daunting as pre-built components are a bit scarce. The learning and productivity curve for Wicket can be a bit steep, but the upside is that once you've made components (and "behaviours" - longer story) that fit your needs, they are extremely reusable.

Wicket 项目只关注核心 Web 框架，没有额外的“好处”，例如特殊的 ORM 支持或脚手架。我个人同意 Wicket 项目的理念，但对于新加入该框架的开发人员来说，做“简单”的事情（例如可排序和可分页的表）可能有点令人生畏，因为预构建的组件有点稀缺。Wicket 的学习和生产力曲线可能有点陡峭，但好处是一旦您制作了满足您需求的组件（和“行为”——长话短说），它们就非常可重用。

Although I personally love Wicket, I have a hunch that you probably will be best off with Play. Your question indicates that you want a "Django" with access to Java libs, and in that case I think Play (or some other Java MVC) is the safe choice. On the other hand, maybe you've been using Django because you didn't know how incredibly powerful Wicket is. ;) If you give some more info on your project, we'll be able to give a more qualified response.

虽然我个人喜欢 Wicket，但我有一种预感，您可能会最适合使用 Play。您的问题表明您想要一个可以访问 Java 库的“Django”，在这种情况下，我认为 Play（或其他一些 Java MVC）是安全的选择。另一方面，也许您一直在使用 Django，因为您不知道 Wicket 有多么强大。;) 如果您提供有关您的项目的更多信息，我们将能够提供更合格的答复。

As a side-node: As Play is not very mainstream (at least for now), I'd also consider Grailswhich has strong commercial backing and even more out-of-the-box modules.

作为一个辅助节点：由于 Play 还不是很主流（至少目前是这样），我也会考虑Grails，它具有强大的商业支持和更多的开箱即用模块。

回答by David Winslow

Play! is designed to be comfortable for developers coming from scripting languages like Python and PHP. It provides its own build system and management scripts, somewhat like Rails or Django would. Existing build tools and infrastructure (like the Maven repositories commonly used for dependency management in Java-land) will not integrate well with Play.

玩！旨在让来自 Python 和 PHP 等脚本语言的开发人员感到舒适。它提供了自己的构建系统和管理脚本，有点像 Rails 或 Django。现有的构建工具和基础设施（如 Java 领域常用的依赖管理的 Maven 存储库）将无法与 Play 很好地集成。

Wicket will be more comfortable for developers coming from desktop development in Java. It doesn't provide special tooling, so it will be easier to integrate into a specific build tool if you have a preference (and there are many build tools providing things like automated dependency retrieval available in the Java ecosystem.)

对于来自 Java 桌面开发的开发人员来说，Wicket 会更舒服。它不提供特殊工具，因此如果您有偏好，将更容易集成到特定的构建工具中（并且有许多构建工具提供了 Java 生态系统中可用的自动依赖检索等功能。）

So there's quite some difference between the two options :) If you can figure out which experience would benefit you most, the decision should be pretty clear from there.

所以这两个选项之间有很大的不同:) 如果你能弄清楚哪种体验对你最有利，那么决定应该很清楚。

回答by smallufo

If your system is only for Web tier , Play! framework is very suitable. But, if your data models are not just for web , maybe exported as REST by Spring with CXF, and consumed by GWT or other web services , and you want to make sure the consistent states with web tier , Wicket (with Spring/hibernate) is a good choice.

如果您的系统仅用于 Web 层，请玩！框架非常适合。But，如果您的数据模型不仅适用于 Web，可能exported as REST by Spring with CXF还被 GWT 或其他 Web 服务使用，并且您想确保与 Web 层的状态一致，Wicket（使用 Spring/hibernate）是一个不错的选择。

Something I don't feel so good about Play! is the caching mechanism. You have to manually naming/insert/retrieve/invalidate/purge cache . This will make the whole architecture error-prone. While wicket with spring/JPA(hibernate)/ehcache(or other providers) , you can define consistent caching/dao layer for upper layer (web/REST...) , which will not impose state inconsistencies.

我对 Play 的感觉不太好！是缓存机制。您必须手动命名/插入/检索/无效/清除缓存。这将使整个架构容易出错。在使用 spring/JPA(hibernate)/ehcache(或其他提供者) wicket 时，您可以为上层 (web/REST...) 定义一致的缓存/dao 层，这不会强加状态不一致。

Another advantage with wicket is it has built-in AJAX support backed by Java . Although these AJAX's states are maintained in the server side (and maybe a little sluggish) , if you don't want to learn JavaScript , you can still build a 'not-so-bad' AJAX page .

wicket 的另一个优点是它具有由 Java 支持的内置 AJAX 支持。虽然这些 AJAX 的状态是在服务器端维护的（可能有点迟钝），但如果你不想学习 JavaScript，你仍然可以构建一个“还不错”的 AJAX 页面。

With Play! , If you don't know about JS , and don't want to learn it , don't want to manipulate cumbersome DOMs , you can only build an 'average' site. OTOH , if you are skilled with JS / jQuery , you can choose Play! .

随着玩！，如果你对JS不了解，也不想学习，不想操作繁琐的DOM，只能搭建一个‘一般’的网站。OTOH，如果你精通JS/jQuery，你可以选择Play！.

回答by eriq

I'm using PLay! a lot and have used Wicket for a bit of evaluation. My experience is, that you have to write a lot more code to get the same work done with Wicket. You have more "indirection" with Wicket. I personally prefer code that has as little as possible "ceremony" and that is easy to follow.

我正在使用 PLAY！很多，并使用 Wicket 进行了一些评估。我的经验是，您必须编写更多代码才能使用 Wicket 完成相同的工作。你有更多的“间接”与 Wicket。我个人更喜欢具有尽可能少“仪式”并且易于遵循的代码。

The Play! architects are also adding Scala support to Play!, which I think is a great idea, since Scala is fully interoperable with Java code and libraries but by far more advanced then Java.

表演！架构师还为 Play! 添加了 Scala 支持，我认为这是一个好主意，因为 Scala 可以与 Java 代码和库完全互操作，但比 Java 先进得多。