现在选择Java Web Framework? [关闭]

问题

我们正处于将基于自定义开发的mvc框架构建的大型网站迁移到基于Java的Web框架的规划阶段,该框架提供对ajax,富媒体内容,mashup,基于模板的布局,验证,最大html /的内置支持java代码分离。 Grails看起来是个不错的选择,但是,我们不想使用脚本语言。我们想继续使用java。基于模板的布局是一个主要问题,因为我们打算将此Web应用程序与具有类似功能但外观和外观完全不同的多个网站一起使用。

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

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

我确实找到类似的帖子,如this,但它已经超过一年了。事情肯定在同一时间发生了变化!

**编辑1:**感谢你的回答!这个网站正在成为在战壕程序员信息中最好的单一来源。但是,我期待有关使用portal-cms二人组的更多信息。 Jahia看起来像货物。有什么相似的吗?


#1 热门回答(146 赞)

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

就个人而言,我会远离大型胖门户解决方案(他们通常是生产力杀手)。我听说过很多关于Gatein的事情,但我没有任何真正的经验。

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

关于Spring Roo,我已经通过互联网阅读了之前的答案,如Spring roo Vs (Wicket and Spring)和其他内容,但我仍然不相信(也许我没有得到它)​​,我不确定它的成熟度,更重要的是,我是真的很想知道SpringSource在Grails和Roo上做了什么(不,Grails vs Roo - why SpringSource is pushing two very similar technologies?并没有说服我,他们都会幸存下来)。

我不能多说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 vs. Struts2以了解它)。
  • GWT,Flex,Grails:这些可能不是你想要的。我无法真正谈论Flex和GWT的最新版本,但我知道Grails确实有一些粉丝。

实际上,我建议你看一下Matt Raible的presentations,他在比较网页框架,展示自己的优势和劣势,收集事实和数据,展示趋势方面做得非常出色......我建议:

  • 比较JSF,Spring MVC,Stripes,Struts 2,Tapestry和Wicket(仍然没有过时)
  • 未来的Web框架:Flex,GWT,Rails和Grails(只是为了尝试其他选择)
  • 比较Kick-Ass Web框架(这是最新的)

真的,看看这些演示文稿,它们将帮助你找到合适的框架(没有唯一的答案,但你可以通过消除来限制选择)并可能改变你的观点。


#2 热门回答(41 赞)

我一直在使用Spring 3和Jquery一段时间,但听说过Play并试了一下。我非常喜欢它,Play非常适合PHP和像Spring这样的重型Java框架。

我最喜欢玩的东西是:

  • 非常容易获得一个播放应用程序,你必须在编码和配置方面走得很远才能在Spring屏幕上获得一个简单的crud应用程序(尽管Spring 3使它变得更容易)。
  • Spring Security非常棒,但却以复杂性为代价。 Play的安全模块非常简单,可满足大约90%的应用程序的需求。
  • 你可以在浏览器中进行代码更改并点击刷新,以查看与PHP类似的更改,而不必使用基于Servlet的框架进行整个重新部署。
  • 错误消息显示得很好,而且大部分时间都不那么神秘。播放仍然需要处理他们的错误处理
  • 有一个Play的插件机制非常简单。
  • 对象持久性非常好地完成,内存数据库和JPA随框架一起提供,因此没有外部对象持久性工具的配置。从内存数据库到实际的RDBMS是配置文件中的一行更改。
  • MVC设置完成得非常好。你扩展以创建域对象的Model类与JPA实体管理器集成。他们不仅仅是POJO。
  • 将URL映射到控制器简单而灵活,并且都在一个"路由"文件中。
  • 每当你创建一个项目Play时都会处理所有的jar依赖项,并且Play有一个eclipse-ify(或你喜欢的任何IDE)的实用程序,以便它直接导入你喜欢的IDE。

我不喜欢Play的事情

  • 文档还没有完全存在,许多未记录的功能仍然存在。
  • 框架是服务器,因此你必须将端口专用于每个应用程序。我认为有人正在开发一个虚拟主机插件,但我还没有看到它的实际应用。
  • 它很年轻,项目很棒,技术很棒,但它真的需要更多的开发人员。我很乐意花一些时间,我们会看到。

#3 热门回答(17 赞)

我的首选是Wicket。清楚地分离标记和java代码。非常容易编写和使用组件。易于使用Ajax,可测试性。你可以直接调试到你的页面/组件,也不会从JSF实现中获得神秘的错误消息;)

还有一个很好的比较wicket < - > JSF interms of performance