各种 Java Web 表示层技术的优缺点

发布于 2024-07-13 22:19:07 字数 392 浏览 5 评论 0原文

我目前正在开发一个大量使用 JSF 和 IceFaces 的 Web 应用程序。 我们已经就转移到另一个表示层进行了一些讨论,我想我应该将讨论放到 SO 中,看看专家们的想法。

我很好奇是否有人可以权衡各种 Java 表示层技术的优缺点。 如果您只使用过一种产品,请说出您喜欢或讨厌它的原因。 如果您曾与几个人合作过,请留下您对他们如何相互比较的印象。

我们正在考虑的技术有:

  • IceFaces
  • JSF(不带 IceFaces)
  • GWT(Google Web Toolkit)
  • Wicket
  • Tapestry

如果我遗漏了列表中的任何内容,请告诉我。

谢谢!

I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think.

I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.

Our technologies under consideration are:

  • IceFaces
  • JSF (without IceFaces)
  • GWT (Google Web Toolkit)
  • Wicket
  • Tapestry

And if I'm missing anything from my list, let me know.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

许你一世情深 2024-07-20 22:19:07

我的观点非常偏向 Wicket,因为在多次被 JSP 地雷绊倒之后,我已经使用它一段时间了。

Wicket PRO:

  • 布局和代码真正分离。
  • 基于组件,这意味着站点元素的高可重用性; 例如,您可以使用自动标签和 CSS 样式等创建美化表单,只需在组件的构造函数中更改它的 DAO 对象,它就可以在另一个项目中完全重用。
  • 对 Ajax、Portlet 和各种框架等一般直接开箱即用的优秀支持,更重要的是,它不依赖于 slf4j/log4j 以外的任何东西来工作,一切都是可选的!

Wicket 缺点:

  • 开发对一般事物有一些困惑,Wicket 泛型现在有点混乱,尽管它们在 1.4 中已经被清理了很多。
  • 一些组件(例如 Form.onSubmit( )) 需要广泛的子类化或匿名方法重写才能轻松注入行为。 这部分是由于 Wicket 强大的基于事件的设计,但不幸的是,这也意味着很容易使 Wicket 的代码变得混乱。

随机缺点:(也就是说,我没有使用过,但这些是我的意见和/或我听说过的事情)

  • GWT 是基于 JavaScript 的,这对我来说听起来很愚蠢。 主要问题是它让我想起了太多 JSP:s 及其自动生成的类,这些都是可怕的。
  • Tapestry 没有以一种可以在两者之间轻松验证的方式正确地分离标记和代码,这将在将来引起问题。

My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.

Wicket PROs:

  • True separation of layout and code.
  • Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.
  • Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!

Wicket CONs:

  • Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4
  • Some components (like Form.onSubmit()) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.

Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)

  • GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.
  • Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.
另类 2024-07-20 22:19:07

我已经将 GWT 用于几个小项目。 以下是我喜欢它的一些特点:

  1. 默认情况下它是 ajax,因此我不必使其它执行 ajax,它只是随使用 GWT 一起出现的。
  2. 它很好地分离了客户端和服务器端代码。
  3. 我可以使用 junit 对我的客户端代码进行单元测试。
  4. 它可以让您构建清晰、活泼的应用程序,很大程度上是因为它是 ajax。

我不喜欢的事情:

  1. 有些事情没有按预期进行。 例如,我见过点击事件未按预期触发的情况,因此我必须采取解决方法。
  2. 自动部署到在 eclipse 中运行的 tomcat 有时会停止工作,我永远不明白为什么。

I've used GWT for a couple small projects. Here are some things I like about it:

  1. It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.
  2. It's got good separation of client versus server-side code.
  3. I can unit-test my client code using junit
  4. It lets you built crisp, snappy apps, largely because it's ajax.

Things I don't like:

  1. Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.
  2. Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.
无戏配角 2024-07-20 22:19:07

我要问的最大问题是为什么要更改表示层? 这是一个非常昂贵的成本,我可以看到一种技术的好处超过其他技术,其好处与改变的成本一样多......

The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...

流殇 2024-07-20 22:19:07

简而言之:

= JSF =

PROS:

  • 组件架构;
  • 许多图书馆和 工具;
  • 有点好的 IDE 支持

缺点:

  • 重量重,在 CPU/内存学习曲线上都如此;
  • 当某些东西没有按预期工作时,很难调试

= WICKET =

优点:

  • 轻量级;
  • 合理的模板系统;
  • 很好的教程;

缺点:

  • 参考文档的组织性和深度不如教程;
  • 开发团队遇到了一些严重的困难,特别是在成为和孵化项目时。 这导致了对框架的重要方面的混淆,当时我不得不切换到另一个框架,因为这个......

In short:

= JSF =

PROS:

  • component architecture;
  • many libraries & tools;
  • somewhat good IDE support

CONS:

  • heavy weight, both in CPU/memory and learning curve;
  • when something doesn't work as expected, it's difficult to debug

= WICKET =

PROS:

  • lightweight;
  • sensible templating system;
  • good tutorials;

CONS:

  • reference documentation is not so well organized and deep as are the tutorials;
  • development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...
那些过往 2024-07-20 22:19:07

条纹怎么样?

What about Stripes?

递刀给你 2024-07-20 22:19:07

我的选择是Wicket。 已经使用过它并且具有出色的可重用性。 它拥有最活跃的论坛/邮件列表之一。 作为一个问题,几分钟内就会得到答案。 它对 AJAX 有很好的支持。 Wicket 的常见缺点之一是学习曲线陡峭。 好吧,这些是老年的缺点之一,现在已经没有价值了。

JSF:最好远离它。 另一个在 JSF 上开发项目的团队在取得成功后现在正在考虑转向 Wicket。

@Megadix:就像你说的,文档一开始很差,但现在不再这样了。 有一本由 Wicket 开发者编写的优秀书籍,名为《Wicket in Action》。 网站上提供的示例代码也是一个开始和学习的好地方

My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.

JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.

@Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn

赏烟花じ飞满天 2024-07-20 22:19:07

我想知道您是否有一个与 Web 客户端不同的服务层,Web 控制器只需调用该服务层即可完成其工作。

如果这样做,Web UI 技术的选择就可以与后端解耦。 如果它作为合同优先 Web 服务公开,您可以让不同的应用程序共享它。 只要您的客户端可以发送和接收 XML,他们就可以与您的服务进行交互。 想要切换到 Flex? 不用担心 - 将其指向服务并呈现 XML 响应。

I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.

If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.

菊凝晚露 2024-07-20 22:19:07

请参阅我对 Wicket 和 Tapestry 5 的比较: Apache Tapestry 和阿帕奇检票口

See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文