149

我们正处于将基于自定义开发的MVC框架构建的大型网站迁移到基于 Java 的 Web 框架的计划阶段，该框架为Ajax、富媒体内容、混搭、基于模板的布局、验证、最大HTML/Java 代码分离。

Grails看起来是个不错的选择，但是，我们不想使用脚本语言。我们想继续使用 Java。基于模板的布局是一个主要关注点，因为我们打算将此 Web 应用程序与具有相似功能但外观和感觉截然不同的多个网站一起使用。

基于门户的解决方案是否适合解决这个问题？

任何有关使用“Spring Roo”或“Play”的见解都会非常有帮助。

我确实找到了类似的帖子，但它已经有一年多了。与此同时，情况肯定发生了变化！

感谢您的精彩回答！这个网站正在成为最优秀的程序员信息的单一来源。但是，我期待更多有关使用 portal-cms duo 的信息。Jahia看起来不错。有没有类似的？

4

16 回答 16

147

基于门户的解决方案是否适合此问题？

就个人而言，我会远离大型的 Portal 解决方案（它们通常是生产力杀手）。虽然我听说过关于Gatein的好消息，但我没有任何真正的经验。

任何有关使用“Spring Roo”或“Play”的见解都会非常有帮助。

关于 Spring Roo，我已经阅读过以前的答案，例如Spring roo Vs（Wicket 和 Spring）以及互联网上的其他内容，但我仍然不相信（也许我不明白），我不确定它的成熟度，而且，更重要的是，我真的想知道 SpringSource 对 Grails 和 Roo 做了什么（不，Grails 与 Roo - 为什么 SpringSource 正在推动两种非常相似的技术？并不能说服我他们都会生存下来）。

关于Play，我不能说太多。我和大家一样看过演示，但我想阅读现实生活中的反馈。在那之前，我会等。

我确实找到了类似的帖子（...）。与此同时，情况肯定发生了变化！

是也不是 :) 但是让我们进入演示框架地狱吧：您的问题没有单一的答案（就像一年前一样），那里有十几个框架，没有明显的赢家。仅举几例：

  • JSF：很多人对这个基于组件的框架持怀疑态度，包括我在内，所以我不是最适合谈论它的人，但是......
  • JSF 2 (+ CDI/Weld)：鼓励 JSF 怀疑论者（Gavin King）“再看一遍”。确实，我认为 JSF 2 是一个很大的改进，尤其是 CDI，但是……它仍然很新（理解，它缺乏反馈）。如果您想拥抱 Java EE 6，请检查一下。
  • Wicket：另一个越来越受到关注的基于组件的框架。我听到的大多是关于它的好东西：比 JSF 更简单、设计精美、可测试性高、HTML 设计器友好等。你可能会喜欢它。
  • Tapestry：只是不要（请参阅为什么停止使用 Tapestry？）
  • Struts 2、Spring MVC、Stripes：基于动作的框架。一切都不错，将满足您的需求（就我个人而言，我喜欢 Stripes 及其约定优于配置的方法，请参阅Stripes 与 Struts2来了解它）。
  • GWT、Flex、Grails：这些可能不是您想要的。我不能真正谈论 Flex 和 GWT 的（最新版本），但我知道 Grails 确实有 一些 粉丝。

实际上，我建议看看 Matt Raible 的演示文稿，他在比较 Web 框架、展示它们的优缺点、收集事实和数字、展示趋势方面做得非常出色……我建议：

真的，看看这些演示文稿，它们将帮助您找到一个合适的框架（没有唯一的答案，但您可以通过排除来限制选择）并且可能会改变您的观点。

于 2010-01-18T07:36:25.487 回答
41

我一直在使用Spring 3 3 和 jQuery，但听说过Play并试了一下。我真的很喜欢它，Play 非常适合 PHP 之类的东西和 Spring 之类的重型 Java 框架。

我最喜欢玩的地方是：

  • 开发一个 play 应用程序非常容易，您必须在编码和配置方面走得很远，才能使用 Spring 在屏幕上获得一个简单的 crud 应用程序（尽管 Spring 3 让它变得容易多了）。
  • Spring Security 很棒，但它是以复杂性为代价的。Play 的安全模块非常简单，涵盖了大约 90% 的应用程序的需求。
  • 您可以更改代码并在浏览器中点击刷新以查看更改，就像使用 PHP 一样，而不必使用基于 Servlet 的框架进行整个重新部署。
  • 大多数时候，错误消息显示得很好，而且不那么神秘。Play 仍然需要处理错误
  • Play 有一个非常简单的插件机制。
  • 对象持久性非常好，因为框架附带了内存数据库和JPA ，因此无需配置外部对象持久性工具。从内存数据库到实际的 RDBMS 是配置文件中的一行更改。
  • MVC 设置做得很好。您为创建域对象而扩展的 Model 类与 JPA 实体管理器集成。它们不仅仅是POJO。
  • 将 URL 映射到控制器既简单又灵活，并且都在一个“路由”文件中。
  • 每当您创建项目时，Play 都会处理所有 JAR 依赖项，并且 Play 有一个实用程序来eclipse -ify（或任何您喜欢的 IDE）项目，以便将其直接导入您喜欢的 IDE。

我不喜欢 Play 的地方

  • 文档还没有全部完成，许多未记录的功能仍然存在。
  • 框架是服务器，因此您必须为每个应用程序指定一个端口。我认为有人正在开发虚拟主机插件，但我还没有看到它在起作用。
  • 它很年轻，项目很棒，技术也很棒，但它确实需要更多的开发人员。我很想花一些时间来解决这个问题，我们拭目以待。
于 2010-07-29T16:39:52.037 回答
17

我的首选是Wicket。

它有：

  • 标记和 Java 代码的清晰分离。
  • 非常容易编写和使用组件。
  • 简单易用的 Ajax
  • 可测试性。

您可以直接调试到您的页面/组件中，并且不会从您的JSF实现中获得神秘的错误消息；）

在性能方面还有一个很好的比较 wicket <--> JSF 。

于 2010-01-18T09:26:53.210 回答
13

我的前三个选择是（按字母顺序）：

他们：

  • 有良好的 Ajax 支持
  • 允许您制作实际的网站，而不是应用程序（如GWT）
  • 稳定，有据可查，广泛使用
  • MVC
  • 纯Java
  • 与 Spring 作为中间件轻松集成
于 2010-01-18T06:56:02.400 回答
11

Play与Ruby on Rails非常相似——Java 中的https://en.wikipedia.org/wiki/Ruby_on_Rails版本。

于 2010-01-18T07:59:11.930 回答
10

与其他答案相比，我想强调流行 Web 框架的缺点（恕我直言）：

JSF 2 - 已发布并已老化。仍然只有一些新闻/文章/博客文章/经验。我很怀疑。仍在等待完全支持 JSF 2 的 Richfaces/Icefaces 的下一个主要版本——目前只能下载 alpha 版本。

Struts 2 - 如果您仍然依赖 struts 并且想要重构大部分代码，这似乎只是一件好事。否则：不要。

GWT - 我不喜欢单页和 Java → JavaScript 方法。我不确定是否可以轻松实现一个会话 - 多个视图/窗口。对我来说，这个框架应该用于海量用户的单窗口富互联网应用。

Wicket - 不错的方法，但有点冗长且可用的文档太少（除了行动书中的好 wicket，但这仅涵盖 1.3）。此外，对我来说，它缺乏建立在它之上的大型项目。而且我目前看不到检票口的路在哪里，或者它是否已经被逼到了死胡同。

Spring MVC - 我还没有尝试过，但是你必须在你的类路径中包含许多 JAR 文件（Spring mess）才能正确使用这个框架。它依赖于JSP（在大多数项目中），我认为它已经死了。你只得到一个纯 MVC 框架——所有其他的东西（ Ajax和其他）都必须实现/集成。

Stripes - 一个小型且设计精美的 MVC 框架，但文档太少，提交/提交者太少，发布太少，行业支持太少，邮件列表活动太少。

我也很好奇我是否错过了一个主要框架（我故意离开Tapestry），这可能是你的一个选择（对我来说也是）。

于 2010-06-16T08:53:11.967 回答
8

我在JAX-RS上取得了巨大的成功。它是唯一具有某种JSR规范和除 servlet 和 portlet 规范之外的多种实现的 Java Web 框架（尽管这可能是一件坏事）。

关于 Java 的一件好事和坏事是你可以选择和匹配框架（Python 也有这个特性/问题）。这很好，因为你不必把所有的鸡蛋都放在一个篮子里。

这是一个通用的 Java Web 应用程序堆栈配方：

JavaScript/Flash + 请求/响应处理 + 依赖注入 + 持久化

JavaScript： jQuery、原型、Dojo

请求/响应： Spring MVC、Stripes 和我最喜欢的 JAX-RS（Jersey、Apache CXF）

依赖注入： Spring、Guice

持久性： JPA（Hibernate、Google App 存储）、Hibernate、JDO等等。

我在使用AspectJ使 Java “少吸”方面也取得了巨大的成功。通过使用 Spring 的 @Configurable 和 AspectJ 的 ITD 混合，您可以获得类似Ruby on Rails的域对象（这实际上是 Roo 所做的，但您不需要 Roo 来执行此操作）。

于 2010-11-30T19:44:43.933 回答
6

我发现Stripes非常有效并且非常轻巧……它的目标是比Struts更轻巧。

我从全职 Web 开发人员的朋友那里听说JSF不值得打扰，尽管我没有第一手经验，也无法通过示例来支持这一点（！）。

于 2010-01-18T09:47:30.443 回答
5

看看RESThub ，它遵循与Play相同的原则！但它是通过重用一些企业级框架/工具来实现的，例如Maven 3、Spring Framework 3、Jersey和 jQuery。

与其他框架相比，RESThub 非常具有破坏性，因为它是一个全栈工具包，但没有任何基于服务器端 MVC 或 servlet 的框架。相反，它使用基于jQuery UI的 GUI，该 GUI 使用JAX-RS ( REST ) Web 服务和基于 EmbeddedJs 的 JavaScript 模板系统。

服务器是无状态的，我们使用 HTML5 sessionStorage 在客户端保持会话。此方法专为RIA和可扩展性而设计。

提供了一些演示应用程序（即使正在建设中）。

于 2010-05-18T12:51:11.657 回答
3

JSF是一个不错的框架，但是 JSF 1.2 在发布之后的几年里都缺乏远见。JSF 2.0 看起来很有前途，并且从 JSF 1.2 中添加了许多新东西，例如Ajax支持、facelets、注释支持和默认约定（更少的 XML），以及比 1.2 更容易的组件构建。

如果您担心DI支持，它也可以与Spring很好地集成。

于 2010-01-18T07:26:17.277 回答
2

我会支持 Spring 的建议。我不是GWT的忠实粉丝，而且我认为 Java 到 JavaScript 的交叉编译器还没有出现。

我正在开发一个在服务器上使用 Spring 并在客户端使用 jQuery的Ajax应用程序。尽管技术上没有对 jQuery 的“开箱即用”支持，但实现 Spring-MVC AjaxView 非常简单，只需要大约 25 行代码。

于 2010-01-18T06:10:48.677 回答
2

我不得不提到Vaadin。

编程仅在 Java 中完成，采用基于组件的方法。客户端-服务器通信更多的是关于用户交互而不是数据传输，所有业务逻辑都驻留在服务器上。

于 2011-07-23T07:51:42.910 回答
1

分机 GWT + 弹簧

于 2010-01-18T06:55:59.773 回答
1

我认为您正在寻找的是接近Jahia的东西。它支持GWT、混搭、媒体内容等。

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates

http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html

于 2010-01-18T10:17:18.157 回答
1

后台门户软件

几年前，我使用过门户软件“ Backbase ”，但当时还不是很成熟。

但它很好，很容易开发。

于 2010-07-29T16:46:21.887 回答
1

看看ItsNat。

ItsNat 基本上是服务器中的 Java W3C浏览器，非常简单（服务器中的 DHTML），并促进了 Ajax 密集型单页界面应用程序

于 2010-11-04T08:28:25.257 回答