这是半咆哮，半问题。
是否值得使用Grails？我正在尝试开发一个相对简单的数据库驱动的Web应用程序。我的专长是Java，所以Grails自然是个不错的选择。起初我想过使用Spring，JPA和Hibernate，但我之前已经使用过它，并且遇到了各种繁琐的配置和编码工作。 Grails称自己为解决这个问题。
我对Grails最大的挫败感是所有不起作用的小事。我的意思是，它不会像人们直觉认为的那样起作用。边缘非常粗糙。我经常遇到问题。有时这是我对Grails理解的缺乏 - 有时候我发现了合法的Grails错误。
一个主要问题是缺乏良好的Eclipse集成。有一个Groovy和Grails插件，但除了语法高亮之外它没有什么作用。从Java调用Groovy反之亦然configure非常痛苦。没有良好的IDE支持是一个主要的失败。
我会坐下来尝试开发我的网络应用程序。在一天结束时，我意识到我花了大约85％的时间调试与Grails相关的问题。如果它不是Eclipse问题，那么它是eager loading，fetching in the view，one-to-many relationships，weird empty file bug behavior，a weird property/getter bug - 它会一直持续下去。这只是我今天遇到的问题的一个例子。我和Grails最后一次坐下来产生了许多不同的问题。
我有时想知道它是否值得。我很好奇其他人是否经历过这种情况。是否有人真正使用Grails来高效地创建Web应用程序？是否还有其他我需要考虑的快速Web开发框架？
答案 0 :(得分：85)
我们有一个由12名经验丰富的高级Java开发人员组成的团队，他们从0.6B学习Grails，我们仍然在研究基于Grails的项目。我不会心甘情愿地回到Java，我们都松了一口气，打破了如何使用Grails应用程序快速到达某个地方。
这是一场斗争，这并不容易，而且有挫折感。
然而，鉴于我们不断的努力，我们很快就提供了一些东西。有些漏洞，其中很多都有解决方法。
我听说过几个擅长Java的开发人员试图深入研究Grails项目的复杂咒语。我们避开了所有的Java并且使用了纯Grails和Groovy。我们确保我们开始简单，尽可能地管理和尽可能地构建复杂性。我们不敢深入研究，并希望我们的Java知识足以带给我们。
我们最终创造了一些巨大而复杂的东西，它的工作非常出色，并且比编写纯Java / Spring / Hibernate版本更快;并且没有像样的IDE支持，而且在bug方面比现在更糟糕。
关于Eclipse支持，用于Grails / Groovy的唯一真正的IDE是Intellij - 遗憾的是Eclipse支持落后了：遗憾的是：我是一个Eclipse爱好者并且远不是一个Intellij转换 - Grails / Groovy支持打击其他一切尽管。
是的，Grails与Spring相比还不成熟。或者Hibernate。而且我敢打赌，在他们存在的前1.5年里，他们同样充满了问题。
这就是它，将责任放在你身上，注意你将复杂性保持在绝对最低限度，仔细测试（在我们看来）并逐渐和谨慎地建立复杂性。
一旦在堆栈中涉及Spring / Hibernate，就没有Java的快速代码解决方案。 Grails所体现的复杂性反映了Spring / Hibernate自身的复杂性。如果你觉得用纯Java做你的时间会更好，我不会反驳..我仍然有我的WTF但现在陡峭的学习曲线已经落后于我，我想我会再坚持使用Grails了。
答案 1 :(得分：36)
我非常喜欢写grails应用程序有两个原因：
我认为在熟悉grails之后，人们可以非常迅速和优雅地完成他的工作。
对于好的方面来说太多了。负面的是性能，这在两个方面打击了我：部署和测试驱动开发。
我没有设法在单个（租用）服务器上运行超过3个grails应用程序，因为我很快达到了内存和性能限制。包含的框架太多了。
另外，grails的测试人员不值得这个名字。当我进行单元测试时，它们应该在瞬间完成，而不是在10到20秒内完成。所以我发现自己一直在用普通的java编写业务逻辑，因为我可以更快地测试它。但我想这可以通过更好地集成到IDE（eclipse）来解决。
答案 2 :(得分：10)
我认为Spring对Grails的支持将是一个很大的推动力。如果有人可以通过网络上的CRUD移动它，那就是那些人。
我也认为它达到了临界质量。有几本新书将于2009年上市。我认为这些将有助于采用率。
答案 3 :(得分：8)
我完全同意原始的海报情绪。
我们是一家Java + Spring商店，并借此机会尝试Grails。 我们首先创建了一个非常小的测试应用程序，结果很简单，它工作得非常好。我们在这里遇到的主要问题是由于我们对Groovy和Grails缺乏了解。
在取得这一成功（信心提升）之后，我们决定尝试一个稍微大一点的项目。这是一次更痛苦的经历。正如其他人所提到的，我们已经发现了各种各样的漏洞和问题，这些漏洞和问题在表面上并不是很明显。应用程序重启周期变得非常痛苦，除非你有非常好的测试覆盖率，否则进行任何类型的重新分解都是一场噩梦。
真正令人沮丧的是，如果没有单个错误消息，代码就会失败！它只是不起作用，你不知道为什么？
我喜欢JMS，Quartz和Remoting插件的易用性等等。消除了大量繁琐的XML。
我很喜欢GORM，虽然我们也有几个问题。
我不喜欢Groovy的松散类型，以及为了能够捕获大量错误而必须运行应用程序这一事实，让我想起太多PHP或Rails。
在一天结束时，我们问自己是否有可能使用Grails编写一个复杂的可管理软件......
我们有一个Grails应用程序即将投入生产....所以我们会看到。
答案 4 :(得分：7)
我们在web层使用grails +使用hibernate和java在服务层上使用spring。它是经典的三层（Web，逻辑，数据），其中Web是grails，逻辑是用java实现的。与java中通常一样，我们使用bean对象来表示不同层之间的数据。
它运行良好，它是我们案例的最佳解决方案，因为bean对象已经存在，以及数据库结构。根据我们的经验，我认为grails作为Web表示层具有很大的价值，但我会坚持使用java编写业务规则并持久保存应用程序数据 - 因为grails“是”java，所有grails-java集成都很漂亮直线前进。
正如人们在这里所说的，我们使用eclipse来开发grails应用程序并且它的集成性很差。但是，作为其他开发人员的建议，我们从命令行运行grails应用程序，只使用eclipse来保存源文件，并且它可以很好地工作，因为应用程序可以即时更新。
我觉得在其他地方使用grails比在表示层使用grails感觉不舒服。
答案 5 :(得分：6)
我完全和你在一起！ Grails仍然感觉边缘粗糙，将它与Rails进行比较几乎是一个笑话。如果至少错误报告更好一点。但我想这可能也是因为它使用了大量的库。一个字：stacktrace！我也不是模型 - ＆gt; db方法的忠实粉丝（Rails有db-＆gt;模型）。脚手架也留有很大的改进空间。然后“不需要重新启动”也不像宣传的那样工作。 （我不确定更糟糕的是 - 不得不一直重新启动或者有时会发现当你重新启动时会消失的怪异行为）并且不要让我开始使用GORM。 （当需要几个小时才能找到一种简单的SQL方法时，你会开始怀疑整个ORM是否真的能节省你的时间）也许只要它很简单。
我的意思是：当你来自java世界时，它仍然是框架的更好选择之一。 （那里有太多无用的垃圾，称自己为网络框架）......它有潜力。我只是希望它不会建立在其他许多复杂的东西之上。
无论如何 - 让我们希望这些东西得到分类。目前我潜伏在playframework.org，这看起来也非常光滑和有希望。
答案 6 :(得分：6)
我在Ruby on Rails上的经验比在Java世界中的任何经验都多，所以我从不同的角度来看。总的来说，Grails 比Rails更加粗糙，部分原因在于它的不成熟，部分原因在于它依赖于两个非常复杂的框架（Spring和Hibernate） 。 Rails还有一个更大的社区。
但是，Groovy作为一门语言已经取得了巨大的进步，并且很高兴与之合作。感谢Groovy 1.6中的改进，Grails比JRuby on Rails更加快捷，并且通过GPath获得了非常好的XML支持。你可以通过JVM获得很多很好的功能（比如并发性和大量的线程安全代码），但是不必沉溺于Java（我不太关心的语言），所以我真的有一个说服自己在MRI上使用任何东西的困难时期。 Python看起来很诱人，但我必须承认。 至于你的Eclipse问题，我无能为力。我使用Vim和Emacs，主要是因为我无法使用IDE。但是对于像Groovy，Ruby和Python这样的动态语言，我认为IDE并不真正带来任何真正的好处，因为实际上没有任何代码生成的地方，或者需要编译。也许尝试在IDE上工作一段时间，看看事情是否更顺畅？ 所以，是的，我认为Grails是值得的。他们已经完成了一项工作，让他们尽可能快地完成工作，Grails和Groovy团队都非常非常专注。
答案 7 :(得分：4)
当他们完成eclipse插件时，它是值得的。我说的越快越好。在发生这种情况之前，试图向我的老板出售groovy并不简单。
答案 8 :(得分：3)
在我开始使用Grails之前，我是一名Eclipse用户。很快就会发现它不会削减它。所以我尝试了Intellij和NetBeans。就Groovy和Grails而言，Intellij当时表现得更好。但是，NetBeans是免费的，这对我来说已经足够了。从那以后，这三个人都发布了新版本或新插件。由于Intellij的成本，我仍在使用NetBeans。通过Spring Source收购G2One，其中一个期望是在Eclipse中支持Groovy和Grails。这对于提高采用率是必要的。
将Grails用于新项目非常棒。因此不再需要大量的Enterprise Java行李。我可以想象尝试移植某些内容会很困难，因为在您了解框架强度和弱点的位置之前，很难有效地利用它。承诺在Grails 1.1中JSP支持会变得更容易，我不知道在尝试使用新框架时是否使用测试版是一个好主意。测试也经历了新版本的重大修订。如果时间允许，您可以考虑等待1.1版本应该很快。
如果您有机会在从头开始创建项目时尝试在不同的IDE中尝试Grails，我认为您将以不同的方式看待它。
答案 9 :(得分：3)
我发现Grails的最大优势在于我不再需要关心数据库 - 模式是自动创建/更新的，并且持久性主要是为我完成的（不再编写SQL查询）。这是一个巨大的解脱。另一件相当不错的事情是，一旦你确定了控制器和视图的模板，添加新的域对象非常快。虽然我怀疑你至少会对你的观点进行持续的改变，但是将它们回溯到现有的观点。
至于IDE - 似乎IntelliJ是最好的选择，但我很高兴使用Netbeans 6.5。我将MyEclipse用于所有其他开发，但Netbeans现在只有更好的Grails支持。
答案 10 :(得分：3)
我刚刚开始在一个新项目中使用grails ...不必编写任何xml文件但仍然具有Spring和Hibernate的强大功能真的很棒。
尽管使用IntellijIDEA作为IDE，我实际上是通过IDE发现了Grails（虽然我可能有偏见，但我讨厌 eclipse）。
答案 11 :(得分：2)
共。有很多Java框架可以为新手设置相当高的标准，并且它证明了Grails能够在如此拥挤的空间中超越它。
它仍然有一些尖锐的边缘，但这些只是时间问题才会失败，基础项目非常值得。
答案 12 :(得分：1)
Grails对于您的应用程序类型可能很大（基于它在第一次初始化时创建的众多文件及其所需的资源）。如果你正在寻找简单的东西，Grails可能不是你想要的。如果你正在寻找一些简单而有效的东西，到目前为止我认为django可以很好地完成你的工作。看看从its tutorial创建CRUD应用程序有多简单（需要多少文件）。从这里开始，随着您的需求和需求的增长，您的应用程序可以（相对）轻松扩展。
答案 13 :(得分：0)
我不确定他们是否能够让你知道Grails。而且，正确的意思是解决所有细节（小的和大的），最终使它感到脆弱和脆弱。我甚至不确定它背后是否有真正的开发团队（意味着超过2人）。
每次我迭代我的Grails项目的一个功能，试图改进某些东西，它是相同的工作流程：一切都崩溃了，然后它是一百个'谷歌'测试周期，然后你找出你可以的原因不做你想做的事，你做别的事。
最后，你很沮丧，因为你甚至不想触摸任何跑步的东西。不好的事情，你放弃它们！
我正在考虑通过JRuby切换到Rails。这可能是两全其美：具有活跃和大型社区的强大Web框架，专门的开发人员团队，不基于Spring或Hibernate等可疑和复杂框架的平台，快速而雄心勃勃的发布周期。而JRuby因为坦率地说，我的背包中有如此多的Java资产，我不能把它们扔掉。
答案 14 :(得分：0)
如果您的专业知识是Java语言。您应该看一下Play Framework - 这是一个受Ruby on Rails启发的Web框架，开发周期非常短 - 只需保存Java源文件并更新Web浏览器即可。如果你想尝试另一种语言，Play Framework有一个让你使用Scala的模块。
我喜欢Play Framework，因为它易于理解且性能良好。如果需要，还可以将JPA和Hibernate用于ORM层。