现在选择Java Web Framework？

Question

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

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

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

我没有找到类似的职位像这样,但它是一个多岁.事情肯定在同一时间发生了变化!

编辑1:谢谢你的答案!这个网站正在成为沟内程序员信息的最佳单一来源.但是,我期待有关使用portal-cms二人组的更多信息.Jahia看起来像货物.有什么相似的吗？

Answer 1

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

就个人而言,我会远离大胖的Portal解决方案(他们通常是生产力杀手).我听说过关于Gatein的好事,但我对它没有任何实际经验.

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

关于Spring Roo,我已经读过像Spring roo Vs(Wicket和Spring)以及互联网上的其他内容之前的答案,但我仍然不相信(也许我没有得到它)​​,我不确定它的成熟度更重要的是,我真的很想知道SpringSource在Grails和Roo上做了什么(不,Grails vs 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 vs. Struts2以了解它).
• GWT,Flex,Grails:这些可能不是你想要的.我无法真正谈论Flex和GWT的最新版本,但我知道Grails确实有 一些 粉丝.

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

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

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

Answer 2

我一直在使用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的事情

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

Answer 3

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

还有一个很好的比较检票口< - >在JSF 的性能方面

Answer 4

我的前三个选择是(按字母顺序):

• JSF
• Spring MVC
• Struts 2

他们:

• 有很好的ajax支持
• 允许您制作实际的网站,而不是应用程序(如GWT)
• 稳定,有据可查,广泛使用
• MVC
• 纯Java
• 与Spring作为中间件轻松集成

Answer 5

Play与ROR非常相似,ROR是java中的ROR版本

Answer 6

与其他答案相比,我想强调流行的Web框架的缺点(恕我直言):

JSF2 - 已发布且已经老化.仍然只有少数新闻/文章/博客文章/经验.我持怀疑态度.仍在等待Richfaces/Icefaces的下一个主要版本,它完全支持jsf 2 - 目前只能下载alpha版本.

Struts 2 - 如果您仍然依赖struts并想重构大部分代码,那似乎只是一件好事.否则:不要.

GWT - 我不喜欢单页和java-> javascript方法.我不确定是否可以轻松实现一个会话 - 多个视图/窗口.对我来说,这个框架应该用于大量用户单窗口富Internet应用程序.

Wicket - 很好的方法,但有点冗长,文档太少(除了行动书中的好检票,但这仅涵盖1.3).另外,对我来说,它缺乏建立在它上面的大项目.我目前无法看到检票口的道路在哪里,或者它已经被驱赶到了死胡同.

Spring MVC - 还没有尝试过,但你必须在类路径中包含许多jar(spring mess)才能正确使用这个框架.它依赖于JSP(在大多数项目中),我认为它已经死了.而且你只获得了一个纯粹的MVC框架 - 所有其他东西(ajax和其他东西)都必须实现/集成.

Stripes - 一个小而精美的MVC框架,但文档太少,提交/提交者太少,版本太少,行业支持太少,邮件列表活动太少.

如果我错过了那里的主要框架(我故意离开了Tapestry),我也很好奇,这可能是你的选择(对我来说也是如此).

Answer 7

我在JAX-RS上取得了很大的成功.它是唯一具有某种JS​​R规范和除servlet和portlet规范之外的多种实现的Java Web Framework(尽管这可能是一件坏事).

关于Java的一件坏事和好事就是你可以选择和匹配框架(python也有这个功能/问题).它很好,因为你不必把所有鸡蛋放在一个篮子里.

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

Javascript/Flash +请求/响应处理+依赖注入+持久性

Javascript: JQuery,Prototype,Dojo

请求/响应: Spring MVC,Stripes和我最喜欢的JAX-RS(Jersey,Apache CXF)

依赖注入: Spring,Guice

持久性: JPA(Hibernate,Google App存储),Hibernate,JDO等.

我在使用AspectJ使Java"少吸收"方面也取得了很大的成功.通过使用Spring的@Configurable和AspectJ的ITD mixins,您可以获得像Domain对象一样的Rails(这实际上是Roo所做的,但是你不需要Roo来做这件事).

Answer 8

我发现条纹真的很有效,而且重量很轻......它的目的是比struts更轻盈.我从朋友那里听说那些是全职的Web开发人员,JSF不值得打扰,虽然我没有第一手经验,也无法用例子(!)来支持.

Answer 9

看看RESThub,遵循与Play相同的原则!但通过重用一些企业级框架/工具(如Maven 3/Spring 3/Jersey/jQuery)来实现.

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

服务器是无状态的,我们使用HTML5 sessionStorage在客户端保持会话.这种方法是针对RIA和可扩展性而设计的.

提供了一些演示应用程序(即使正在构建中).