我在寻找Java中是否有类似于Django/RoR的框架。
我发现了以下两个框架：
有人试用过这些框架吗？或者你知道其他的框架吗？ 它们比Django/RoR更快吗？
Java Web框架
17
- Roch
3
一个Web框架中哪些元素对你来说很重要？可扩展性、生产力、文档等等？ - Joel
可扩展性、生产力、文档化和合理的资源消耗（即使每个人都说这对于 Web 应用程序并不重要，在云环境中它也是重要的）。 - Roch
Rails、Wicket、Grails、Play、Lift、JSP 的基准测试：http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/ - Gelin Luo
18个回答
17
大约一年前我发现了Grails，从此不再回头。它汲取了很多Ruby on Rails的思想（最初是被称为Groovy on Rails），并且有着丰富的插件/扩展生态系统。Grails和其底层语言（Java的超集）让编程变得非常愉快 - 你可以真正专注于核心功能。
它的GORM功能（基于Hibernate的一层）也非常强大，并且除了插件系统之外，是检查它的两个巨大原因之一（你也可以在你的Java应用程序中使用它）。
随着1.2版本即将发布，我认为它具备了足够的特性和成熟度，成为任何开发者必备的工具之一。
就性能而言，它肯定不及纯Java，但你可以利用Spring / Hibernate / J2EE等优化所有部分，并且对于一些关键代码块，你总是可以切换至纯Java。最近进行了一些实验，允许使用静态方法解析来运行部分Groovy代码，结合invokedynamic支持，应该能提供巨大的性能提升。
Java中还有其他值得关注的项目，比如Spring Roo和AribaWeb。
基于其他标准的更新
可扩展性、生产力、文档和合理利用资源
- 可扩展性 - 你可以获得经过验证的Java / Spring / Hibernate堆栈，但我不能说Grails本身提供了太多。
- 生产力 - 这是使用Grails的主要原因。虽然它有性能开销，但是当开发时间/生产力更为重要时，你会使用Grails。
- 文档 - Grails文档很棒，而且至少有三本关于Grails的好书。社区繁荣并且非常乐意帮助。
- 资源消耗 - 这是一个权衡。Grails（部分原因是由于底层Java堆栈）需要消耗更多的资源。如果我正在构建类似Google的东西，Grails不会是我的选择。然而，在任何复杂的Web应用程序中，您都可以使用缓存解决方案来获得良好的效果，因此同样适用于此处。
- Jean Barmash
5
1好的，Grail看起来很不错。但我想试试"Play"，它看起来非常吸引人。我唯一担心的是资源消耗问题，不知道它是比PHP/Python/Ruby更好还是更差，我在Google上没有找到太多相关信息。 - Roch
1听起来不错 - 玩起来看起来很酷。同时也可以查看AribaWeb的视频 - 看起来非常不错。但请记住，使用Grails，您还可以获得Groovy的强大功能，这本身就是一个优势（尽管性能当然是一种权衡）。 - Jean Barmash
好的，我会看一下AribaWeb。Play框架也使用Groovy作为其模板；-) - Roch
与其他Java Web框架相比，Play对资源消耗应该非常容易。它并不强制您使用整个J2EE堆栈，非常轻量级，基本上只是Netty和几个库...只需检查它的启动速度......此外，使用Jetty允许它更智能地使用线程，请参阅本文：http://blog.heroku.com/archives/2011/8/29/play/。 - opensas
1我对Grails感到非常失望。虽然开始一个新项目很快很容易，但是随着项目规模的增大，速度会变慢。调试非常困难，与Java相比，工具支持较差（尽管IntelliJ做得很好）；许多小问题和奇怪的魔法使生活变得艰难。在我上一个Grails项目之后，我希望我能用普通的servlets来完成它！ - deamon
2
每当你考虑一个应用堆栈（语言、框架等）时，你需要考虑的是你要解决什么问题以及你拥有哪些编程技能。我发现，与初级程序员相比，更有经验的Java程序员使用Groovy和Grails堆栈时非常高效。
您提到以下几个方面存在关注点：
可扩展性：具体指什么？（每秒页面浏览量，每秒事务数量等）总的来说，Groovy和Grails在呈现页面方面会进行扩展，但是与任何应用堆栈一样，在使用ORM时（在Grails的情况下，您有GORM），需要考虑一些开销。
生产力：这里的主要优势之一是快速原型制作，使用Groovy和Grails可以轻松进行快速开发，尽管最好有Java或Ruby的开发人员了解Grails框架在“引擎盖下”实际上正在做什么。有大量的UI插件可帮助快速创建类Web 2.0页面。
文档：越来越多的高质量参考书正在为Groovy和Grails编写。过去2年，两者都得到了很好的发展。当遇到错误/问题时，关于Grails框架的许多内部工作并没有很好的记录（框架的大部分输出在面对错误时是模糊或不存在的）。如果您愿意卷起袖子并善于通过内部工作进行资源管理，那么您将不会对此堆栈感到失望。同样，有经验的程序员会发现这是一种第二天性，而初级人员有时可能会放弃。
资源消耗：存在开销，但是对于今天找到的大多数硬件（本地或云），我不会太担心给定应用程序实例的物理资源消耗。
希望这可以帮助到您。
您提到以下几个方面存在关注点：
可扩展性：具体指什么？（每秒页面浏览量，每秒事务数量等）总的来说，Groovy和Grails在呈现页面方面会进行扩展，但是与任何应用堆栈一样，在使用ORM时（在Grails的情况下，您有GORM），需要考虑一些开销。
生产力：这里的主要优势之一是快速原型制作，使用Groovy和Grails可以轻松进行快速开发，尽管最好有Java或Ruby的开发人员了解Grails框架在“引擎盖下”实际上正在做什么。有大量的UI插件可帮助快速创建类Web 2.0页面。
文档：越来越多的高质量参考书正在为Groovy和Grails编写。过去2年，两者都得到了很好的发展。当遇到错误/问题时，关于Grails框架的许多内部工作并没有很好的记录（框架的大部分输出在面对错误时是模糊或不存在的）。如果您愿意卷起袖子并善于通过内部工作进行资源管理，那么您将不会对此堆栈感到失望。同样，有经验的程序员会发现这是一种第二天性，而初级人员有时可能会放弃。
资源消耗：存在开销，但是对于今天找到的大多数硬件（本地或云），我不会太担心给定应用程序实例的物理资源消耗。
希望这可以帮助到您。
- timarmandpour
2
使用过struts、wicket、rails和Tapestry后，我建议你看看Tapestry 5。
它支持：
- 容器内类重载（无需每次更改都重新启动Web应用程序） - 快速开发时间和提高生产力 - 它使用基于组件的模型，具有声明性连线 - 最小化配置，大部分都在代码中，约定优于配置等。 - 无需扩展基类 - 在模板文件中使用表达式语言 - 良好的ajax支持 - 出色的调试支持，客户端和服务器端都有 - 良好的数据访问集成 - 积极的社区 - 从头开始编写，考虑了性能。例如页面池化（以最小化资源使用），页面压缩，消除空格，所有动态代码都编译为本机代码。 - 良好的bean和表单支持-使常见任务变得简单。可通过仅使用一行模板代码和最小的骨架服务器后端来编写可排序的数据库支持的drid。
唯一的缺点是文档，虽然不错，但有点简洁，但用户组/邮件列表非常活跃，大多数问题都得到了很好和热情的回答。
（此外，请确保仅查看T5-而不是T4、3、2、1......因为它们与当前版本非常不同）
更多关于这里。
它支持：
- 容器内类重载（无需每次更改都重新启动Web应用程序） - 快速开发时间和提高生产力 - 它使用基于组件的模型，具有声明性连线 - 最小化配置，大部分都在代码中，约定优于配置等。 - 无需扩展基类 - 在模板文件中使用表达式语言 - 良好的ajax支持 - 出色的调试支持，客户端和服务器端都有 - 良好的数据访问集成 - 积极的社区 - 从头开始编写，考虑了性能。例如页面池化（以最小化资源使用），页面压缩，消除空格，所有动态代码都编译为本机代码。 - 良好的bean和表单支持-使常见任务变得简单。可通过仅使用一行模板代码和最小的骨架服务器后端来编写可排序的数据库支持的drid。
唯一的缺点是文档，虽然不错，但有点简洁，但用户组/邮件列表非常活跃，大多数问题都得到了很好和热情的回答。
（此外，请确保仅查看T5-而不是T4、3、2、1......因为它们与当前版本非常不同）
更多关于这里。
- Joel
1
我曾经用Grails做过一个项目，发现它在某些任务上非常快，但是它在幕后做了很多“魔法”，这使得调试变得困难。
此外，我发现自己一遍又一遍地阅读文档，因为我觉得它不够自然。一个简单的例子是控制器，其中操作被定义为字段（对我来说，将操作视为方法是很自然的...）。关于GORM，你需要知道一些特殊的词语，当放置在静态字段中时，会执行一些魔法，比如使字段瞬态化...没有注释，没有自动完成...只有手动。
至于Play！，我发现它非常简单和快速，易于学习和记忆。社区似乎比Grail's小，但更活跃，回答更快。唯一的缺点是它不依赖于servlet的api，因此一些第三方过滤器或其他东西很难集成，但并非不可能。重要的是要注意，您可以将Play应用程序部署在任何传统的Web服务器上，将其打包为war文件。
我认为Grails很棒，但你需要有很多经验才能提高生产力，否则你会花费很多时间在手册上。因此，如果你不是这种情况，我应该推荐Play！特别是如果你不熟悉Groovy。
- Gastón Fournier
1
关于JRoR怎么样？
- jitter
2
2JRuby on Rails不是一个Java Web框架！它是在JVM上运行的Ruby on Rails。 - John Topley
1问题本身也犯了同样的错误，所以问问题的人可能不仅指Java :) - Bozho
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接