Java 我应该选择哪个框架 - Seam、Wicket、JSF 或 GWT？

Which framework should I choose - Seam, Wicket, JSF or GWT?

提问by karl

I'm debating whether to use Seam, Wicket, JSF or GWT as the foundation for my presentation layer in a Java project.

我正在争论是使用 Seam、Wicket、JSF 还是 GWT 作为 Java 项目中表示层的基础。

I narrowed my selection of Java web frameworks down to this subset based on job market considerations, newness of the technology and recommendations from other S.O. users.

根据就业市场的考虑、技术的新鲜度和其他 SO 用户的建议，我将 Java Web 框架的选择范围缩小到这个子集。

What factors should I take into consideration in deciding among these?

在选择这些时，我应该考虑哪些因素？

采纳答案by digitaljoel

The only one of those I've used is JSF, so I won't be able to give you feedback on the others, but here's my take on JSF. In my experience, the minute we converted from JSF in JSP to JSF in facelets, life got MUCH easier, so I'll focus around facelets. Also, It looks like Seam and JSF are not mutually exclusive.

我唯一使用过的其中一个是 JSF，所以我不能给你关于其他的反馈，但这是我对 JSF 的看法。根据我的经验，当我们从 JSP 中的 JSF 转换为 facelets 中的 JSF 时，生活变得更容易了，所以我将专注于 facelets。此外，看起来 Seam 和 JSF 并不相互排斥。

Pros:

优点：

• Creating facelets xhtml components is simple, which promotes re-use.
• Decent templating abilities using built in tags like ui:insert, ui:include, and ui:decorate
• Simple access to Spring beans through faces-config
• XHTML based so web developers unfamiliar with java can still be effective
• Good widget library available in tomahawk/trinidad

• 创建 facelets xhtml 组件很简单，这促进了重用。
• 使用内置标签（如 ui:insert、ui:include 和 ui:decorate）的体面模板能力
• 通过faces-config简单访问Spring bean
• 基于 XHTML，因此不熟悉 java 的 web 开发人员仍然可以有效
• tomahawk/trinidad 中提供了很好的小部件库

Cons:

缺点：

• Post requests only. This can make bookmarking difficult.
• Not as built-in ajax-y as GWT, but this may be fixed if used with Seam

• 仅发布请求。这会使书签变得困难。
• 不像 GWT 那样内置 ajax-y，但如果与 Seam 一起使用，这可能会得到修复

I'm by no means an expert in JSF/Facelets, so I'm sure there are others I've missed. Hopefully someone else will also elaborate.

我绝不是 JSF/Facelets 方面的专家，所以我确定我错过了其他人。希望其他人也能详细说明。

Update for JSF 2.0:

JSF 2.0 更新：

• Has even better re-use capabilities with composite components
• Widget libraries for 2.0 include primefaces and mojarra scales
• Allows get requests and bookmarking
• Has built in Ajax support
• See http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/for more on JSF 2

• 对复合组件具有更好的重用能力
• 2.0 的小部件库包括 primefaces 和 mojarra scales
• 允许获取请求和书签
• 已内置 Ajax 支持
• 有关JSF 2 的更多信息，请参阅http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

回答by recampbell

Seam is an application framework, not really a presentation layer. It was originally developed to make JSF less painful, but has evolved into a more general purpose dependency injection framework.

Seam 是一个应用程序框架，而不是真正的表示层。它最初是为了让 JSF 减少痛苦而开发的，但已经演变成一个更通用的依赖注入框架。

I believe that you can use Seam with JSF, Wicket and GWT. JSF support is primary and excellent; I'm not sure how well the other two are supported.

我相信您可以将 Seam 与 JSF、Wicket 和 GWT 一起使用。JSF 支持是主要的和优秀的；我不确定其他两个的支持情况如何。

Since the focus of your criteria seem to be the marketability of your skills, I would suggest trying out Seam and JSF via Facelets. JSF is a well accepted standard and is actually enjoyable to use if you are using Facelets. You can have slick AJAX functionality via Richfaces and Ajax4jsf. Seam is being more or less standardized via the JCP.

由于您的标准的重点似乎是您技能的适销性，我建议通过 Facelets 尝试 Seam 和 JSF。JSF 是一个广为接受的标准，如果您使用的是 Facelets，实际上使用起来会很愉快。您可以通过 Richfaces 和 Ajax4jsf 获得灵活的 AJAX 功能。通过 JCP，Seam 或多或少地被标准化。

回答by Thorbj?rn Ravn Andersen

In a long term scenario I'd recommend using technologies backed by a Sun specification. This has so far proven to give multiple implementations resulting in choice (frequently also open source implementations), plus behaviour tends to be very well defined.

从长远来看，我建议使用由 Sun 规范支持的技术。到目前为止，这已经证明可以提供多种实现方式来进行选择（通常也是开源实现方式），而且行为往往被很好地定义。

That will help you in a maintainance scenario, which - hopefully - your code will end up too in time. Well-written code lives forever :)

这将在维护场景中为您提供帮助，希望 - 您的代码也能及时结束。写得好的代码永远存在:)

In this particular scenario I would suggest JSF. I have only tried the Apache implementation of 1.1, but it hurt to be on top of JSP. We are to revise it soon - I expect to look into having JSF on facelets.

在这种特殊情况下，我建议使用 JSF。我只尝试过 1.1 的 Apache 实现，但是在 JSP 之上很痛苦。我们将很快对其进行修改 - 我希望研究在 facelets 上使用 JSF。

回答by salk31

I've used Wicket and GWT pretty heavily. Never really learned to love Wicket.

我已经大量使用 Wicket 和 GWT。从未真正学会爱 Wicket。

My ego blogged about it http://salk31.blogspot.com/2009/07/wicket-ajax.html

我的自我在博客上写了它http://salk31.blogspot.com/2009/07/wicket-ajax.html

Looking at GWT 2.0 uiBinder today reminded me how annoying it was in Wicket to have to match the XML component tree with the one created in Java. The GWT spin on this looks vastly better to me.

今天看看 GWT 2.0 uiBinder 提醒我，在 Wicket 中必须将 XML 组件树与在 Java 中创建的组件树相匹配是多么烦人。GWT 对此的看法对我来说要好得多。

I've not used Wicket for over a year so maybe they have fixed a lot of this but given modern browser and JS support I can't see the point of doing all this on the server (I know, I know data locality).

我已经一年多没有使用 Wicket，所以也许他们已经修复了很多问题，但是鉴于现代浏览器和 JS 支持，我看不出在服务器上执行所有这些操作的意义（我知道，我知道数据局部性）。

回答by daud

JSF is deprecated(JSF is not even listed as a framework to compare when evangelists compare or talk about web frameworks in 2010).

JSF 已被弃用（在 2010 年布道者比较或谈论 Web 框架时，JSF 甚至没有被列为要比较的框架）。

Now full fledge large scale applications are created using GWT, YUI, JQuery etc.

现在使用 GWT、YUI、JQuery 等创建成熟的大型应用程序。

Read some articles over google and above will be obvious.

阅读一些谷歌及以上的文章会很明显。

(ALL JOBS on JSF are to support legacy applications).

（JSF 上的所有工作都支持遗留应用程序）。

回答by Gursel Koca

If you consider only job market , you should choose JSF. But, I belive that the future of RIA belongs to GWT and gwt like client side technologies.

如果你只考虑就业市场，你应该选择JSF。但是，我相信 RIA 的未来属于 GWT 和 gwt 之类的客户端技术。

I think that the most obvious upside of GWT, it is better scaleable than server side presentation layer technologies such as JSF, wicket. Because , server does not need to store client state and the client cpu power also are also used.. It is a huge benefit, you dont need to serialize client state between server computers to achive fault tolerant system.

我认为 GWT 最明显的优势是，它比 JSF、wicket 等服务器端表示层技术具有更好的可扩展性。因为，服务器不需要存储客户端状态，客户端cpu的能力也被使用了。这是一个巨大的好处，你不需要在服务器计算机之间序列化客户端状态来实现容错系统。

回答by joshua

Thanks wicket guys for remaining sober and keeping over this discussion. I am a wicket user and i love it. My main reasons are :

感谢检票员保持清醒并继续讨论。我是 wicket 用户，我喜欢它。我的主要原因是：

1. Its a component framework. I love working with components as opposed to full pages.

2. I can let the designers work on the templates and pages as i work on the java parts

3. There is nothing new to learn. Its "just java and just HTML"

4. I like its ajax Fallback mechanism. Where there is not javascript support on a browser especially on mobile devices, it falls back to plain html and everything works.
5. Its lack of xml configuration is a plus
6. It supports everything i would want in a web application. e.g validation, internationalization, back button support and restful URLs among others

1. 它是一个组件框架。我喜欢使用组件而不是整页。

2. 我可以让设计师在我处理 Java 部分时处理模板和页面

3. 没有什么新东西要学。它的“只是 Java 和 HTML”

4. 我喜欢它的 ajax 回退机制。如果浏览器不支持 javascript，尤其是在移动设备上，它会回退到纯 html 并且一切正常。
5. 它缺乏xml配置是一个加分项
6. 它支持我在 Web 应用程序中想要的一切。例如验证、国际化、后退按钮支持和 Restful URLs 等

My previous experience is GWT and JSF 1.0

我之前的经验是 GWT 和 JSF 1.0

回答by Miguel Ping

I've used GWT since version 1.4 and JSF since the 2.0 spec came out.

我从 1.4 版开始使用 GWT，从 2.0 版规范出来后使用 JSF。

GWT is a client-side framework, it generates JavaScript from Java. Your architecture would be a pure client-server, which means:

GWT 是一个客户端框架，它从 Java 生成 JavaScript。您的架构将是一个纯粹的客户端-服务器，这意味着：

• Best to use coarse-grained services
• All objects that travel to the client side should be fully serializable (it means there's no lazy load, or OpenSessionInView pattern)
• Since GWT 2.0 you can design your gui using xhtml, which is much easier in regards to styling & structuring HTML
• GWT tends to favour good architecture, if you mess it up it will be badto refactor
• PerfectHistory (browser back button, bookmarkable urls) support is hard, you probably have to roll your own, although it's easy to hack something right up front

• 最好使用粗粒度服务
• 传送到客户端的所有对象都应该是完全可序列化的（这意味着没有延迟加载或 OpenSessionInView 模式）
• 从 GWT 2.0 开始，您可以使用 xhtml 设计 gui，这在 HTML 样式和结构化方面要容易得多
• GWT倾向于支持好的架构，如果你搞砸了重构就会很糟糕
• 完美历史（浏览器后退按钮，书签网址）支持很难，您可能必须自己动手，尽管很容易在前面破解某些东西

JSF is a component-based framework, with a view-first design (code-behind if you like):

JSF 是一个基于组件的框架，具有视图优先设计（如果您愿意，可以使用代码隐藏）：

• It's easier to do some type of webapps (stateful, like shopping cart)
• JSF+Seam have suport for conversations (think wizard-like pages that maintain state across several pages)
• You canimplement OpenSessionInView, depending on your stack. It's probably not recommended if you use EJB for service/business layer
• JSF2 has superbsupport for AJAX, and with a component suite like RichFaces you can build nice webapps
  • But if you want exquisite javascript behaviour, you'll have to write some javascript
• JSF tracks the current UI state in client or server-side. This is a tradeoff between network traffic or server memory.

• 做某种类型的网络应用程序更容易（有状态的，比如购物车）
• JSF+Seam 支持对话（想想像向导一样的页面，可以跨多个页面维护状态）
• 您可以实现 OpenSessionInView，具体取决于您的堆栈。如果您将 EJB 用于服务/业务层，则可能不推荐
• JSF2对 AJAX有极好的支持，并且使用像 RichFaces 这样的组件套件，您可以构建漂亮的 web 应用程序
  • 但是如果你想要精致的 javascript 行为，你就必须写一些 javascript
• JSF 跟踪客户端或服务器端的当前 UI 状态。这是网络流量或服务器内存之间的权衡。

Resume:

恢复：

• GWTis more adequate for web applications(think gmail) that require the best client-side performance. It's easy to write custom components (you write Java) and since your server-side is just a service layer you can be fully stateless on the server side.
• JSFis more adequate for mostly CRUD applications that are better suited for component-oriented stuff: think a hotel/flight reservation system, an online store with a shopping cart, etc

• GWT更适合需要最佳客户端性能的Web应用程序（想想 gmail）。编写自定义组件很容易（您编写 Java），并且由于您的服务器端只是一个服务层，您可以在服务器端完全无状态。
• JSF更适用于更适合面向组件的大部分 CRUD 应用程序：想想酒店/航班预订系统、带有购物车的在线商店等

回答by Volksman

My experience is, in chronological order:

我的经验是，按时间顺序：

Raw servlets - (yeah, lot's of hard work but the it was early days and we were eager beavers!)

原始 servlet -（是的，很多工作很辛苦，但当时还很早，我们是热切的海狸！）

JSP - I thought it was the beez neez at the time it came out (if we only knew ;) )

JSP - 我以为它出来的时候是beez neez（如果我们只知道;））

Echo - Awesome framework but not for pages that need to be search engine friendly (same problem with GWT)

Echo - 很棒的框架，但不适用于需要对搜索引擎友好的页面（与 GWT 相同的问题）

Wicket - Awesome framework - the developers fully understand the concept of OO (unlike JSP and many others) and have applied all the usual OO niceties to this framework. If you appreciate 'reusability', if you appreciate encapsulation, if you appreciate separation of concerns and if you like to bind your model to the UI code without having to worry about object marshalling and other such ugliness then this is the framework for you!

Wicket - 很棒的框架 - 开发人员完全理解 OO 的概念（与 JSP 和许多其他人不同），并将所有常见的 OO 细节应用于该框架。如果您喜欢“可重用性”，如果您喜欢封装，如果您喜欢关注点分离，并且如果您喜欢将模型绑定到 UI 代码而不必担心对象编组和其他类似问题，那么这就是适合您的框架！

回答by Jean-Rémy Revy

I know it's a bit late but there is already lot of comparison on Framewrok, espcially this one, wich occured durinf Devox 2010 conf :

我知道这有点晚了，但已经有很多关于 Framewrok 的比较，尤其是这个，发生在 durinf Devox 2010 conf 中：

http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks

http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks

This should help you to choose :)

这应该可以帮助您选择:)