Grails值得吗？
这是一半的咆哮，一半的问题。
值得使用Grails吗？ 我试图开发一个相对简单的数据库驱动的Web应用程序。 我的专长是Java，所以Grails自然是一个不错的select。 起初我想过使用Spring，JPA和Hibernate，但是之前我曾经使用过，并且遇到了各种繁琐的configuration和编码工作。 Grails宣称自己正在解决这个问题。
我对Grails最大的挫折是所有不起作用的小事情。 我的意思是，它不会像直觉上认为的那样工作。 边缘很粗糙。 我不断遇到问题。 有时候是因为我缺乏对Grails的理解 – 有时我发现了合法的Grails错误。
一个主要的问题是缺乏良好的Eclipse集成。 有一个Groovy和Grails插件，但除了语法高亮之外，它没有什么其他function。 从Java调用Groovy，反之亦然是非常痛苦的configuration 。 没有良好的IDE支持是一个主要的失望。
我坐下来试图开发我的Web应用程序会发生什么？ 在这一天结束的时候，我意识到我已经花了大约85％的时间来debugging与Grails相关的问题。 如果这不是Eclipse的问题，那么它是加载 ， 视图中获取， 一对多的关系 ， 奇怪的空文件错误的行为 ， 一个奇怪的属性/ getter错误 – 它只是继续下去。 这只是我今天遇到的一些问题。 我最后一次与Grails坐在一起，产生了一大堆不同的问题。
我有时会怀疑它是否值得。 我很好奇，如果别人经历了这一点。 有没有人真正使用Grails来高效地开发Web应用程序？ 有没有其他的快速网站开发框架，我应该考虑？
我们有一个12人的团队，他们都是经验丰富的高级Java开发人员，他们从0.6B开始学习Grails，我们仍然在开发基于Grails的项目。 我不愿意回到Java，我们都很高兴能够打破如何使用Grails应用程序快速获取某个地方的信息。
这是一场斗争，这并不容易，有挫折感。
不过，考虑到我们正在进行的努力，我们很快就做出了一些事情。
我听说过好几位擅长Java的开发人员尝试深入Grails项目的复杂咒语。 我们避开了所有的Java，进入了纯粹的Grails和Groovy。 我们确保我们开始简单，尽可能以可pipe理和实际的方式构build复杂性。我们不敢潜入最深处，希望我们的Java知识足以承载我们。
我们最终创造了一些巨大而复杂的东西，它的function非常出色，比编写纯Java / Spring / Hibernate版本的速度快得多。 那就没有像样的IDE支持，而且错误的情况比今天更糟糕。
关于Eclipse的支持，唯一真正用于Grails / Groovy的IDE是Intellij– Eclipse的支持很落后，可悲的是：我是一个Eclipse的爱好者，远不是Intellij的转换 – Grails / Groovy的支持把所有的东西都带走虽然。
是的，Grails与Spring相比可能还不成熟。 或者hibernate。 我敢打赌，在他们存在的头一年，他们同样充满了问题。
就是这样，把责任放在你身上，照顾你把复杂性降到最低，小心地先testing（在我们看来），逐步小心地逐步复杂化。
一旦将Spring / Hibernate包含在堆栈中，Java就没有快速的代码解决scheme。 Grails所体现的复杂性反映了Spring / Hibernate自身的复杂性。 如果你觉得你花时间用纯Java做的更好，那么我就不会争辩了。我还有我的WTF，但是现在这个陡峭的学习曲线在我身后，我想我会再坚持一下Grails。
我非常喜欢写Grails应用程序，原因有二：
- 我不必使用Java
- 我可以使用Java
我认为，在熟悉Grails之后，我们可以非常快速，优雅地完成他的工作。
非常好的一面。 负面的是性能，这在两个方面打击我：部署和testing驱动的发展。
我还没有设法在单个（租用）服务器上运行3个以上的grails应用程序，因为我很快就遇到了内存和性能限制。 包含的框架太多了。
另外，Grails的testrunner不值得这个名字。 当我运行unit testing时，应该立即完成，而不是在10到20之间。 所以我发现自己一直在用普通的java编写业务逻辑，因为我可以更快地testing它。 但我想这可以通过更好地集成到IDE（日食）来解决。
我认为Spring对Grails的支持将会是一个很大的提升。 如果有人能通过networking上的CRUD移动它，那就是那些人。
我也认为它正在达到一个临界质量。 2009年将有好几本新书上市。我认为这些将有助于采用率。
我完全同意原来的海报情绪。
我们是一家Java + Spring商店，并借此机会试用了Grails。 我们首先创build了一个非常小的testing应用程序，结果非常简单，它工作得很好。 我们在这里遇到的主要问题是由于我们对Groovy和Grails缺乏知识。
在成功之后（信心提升），我们决定尝试一个稍大的项目。 这是一个更加痛苦的经历。 正如其他人所说，我们已经发现了各种各样的表面上并不直接performance出来的错误和问题。 应用程序的重新启动周期变得非常痛苦，除非你有非常好的testing覆盖率，否则这是做任何重新分解的噩梦。
真令人沮丧的是没有一个错误信息的代码失败！ 它只是不起作用，你不知道为什么？
我喜欢JMS，Quartz和Remoting等插件的易用性。 消除了很多乏味的XML。
我很喜欢GORM，虽然我们也有几个问题。
我不喜欢Groovy的松散types的性质，以及为了能够捕获一堆错误而必须运行应用程序的事实，这让我想起了太多的PHP或Rails。
在这一天结束的时候，我们正在问自己是否有可能使用Grails编写一个复杂的可pipe理软件。
我们有一个即将投入生产的Grails应用程序，所以我们将会看到。
我们在web层+ java上使用grails +，在服务层上使用hibernate和spring。 这是经典的三层（networking，逻辑，数据），其中Web是Grails，逻辑是用java实现的。 和java一样，我们使用表示不同图层之间数据的bean对象。
它工作得非常好，对于我们的情况来说，这是最好的解决scheme，因为bean对象已经存在，还有数据库结构。 根据我们的经验，我认为grails作为web表示层有很大的价值，但是我会坚持用java编写业务规则并坚持应用程序数据 – 就像grails“是”java一样，所有的grails-java集成都很漂亮直截了当。
正如人们在这里所说的，我们使用eclipse来开发Grails应用程序，这是一个糟糕的整合。 但是，作为其他开发人员的build议，我们从命令行运行grails应用程序，只使用eclipse来保存源文件，并且它运行得非常好，因为应用程序正在进行更新。
但是在表示层以外的其他地方使用Grails却感觉不舒服。
我完全和你在一起！ Grails在边缘仍然感觉如此粗糙，以至于与Rails进行比较几乎是个玩笑。 如果至less错误报告好一点。 但是我想这可能也是由于它在封面下使用了大量的库。 一个字：stacktrace！ 我也不是模型 – >数据库方法（Rails有db->模型）的大粉丝。 脚手架也留下了很大的改进空间。 然后“不需要重新启动”也不能像广告一样工作。 （我不确定更糟糕的是 – 不得不重新开始，或者有时会发现当你重新启动时会消失的怪异行为）并且不要让我开始使用GORM。 （当需要几个小时才能find一个简单的SQL，你会开始怀疑整个ORM是否真的节省了你的时间）也许只要它很简单。
我的意思是：当你来自Java世界时，它仍然是框架的更好的select之一。 （这么多没用的垃圾，自称是一个Web框架）…它有潜力。 我只希望它不会build立在其他复杂的东西之上。
无论如何 – 让我们希望这些东西得到sorting。 目前我正在潜伏在playframework.org ，这看起来也很光滑，很有希望。
在Ruby on Rails方面我比Java世界有更多的经验，所以我从另一个angular度来介绍。 总的来说，Grails比Rails更加粗糙，部分原因在于它不够成熟，部分原因在于它依赖于两个非常复杂的框架（Spring和Hibernate）。 Rails也有一个更大的社区。
但是，Groovy作为一种语言已经取得了长足的进步，并且很高兴与之合作。 感谢Groovy 1.6所做的改进，Grails比JRuby on Rails更快捷，并且通过GPath获得惊人的XML支持。 在JVM上有很多很好的function（比如并发性和线程安全代码），但是不用沉迷Java（一种我不太在意的语言），所以我真的说服自己在MRI上使用任何东西的困难时期。
Python看起来很诱人，但我必须承认。
至于你的Eclipse问题，我忍不住。 我使用Vim和Emacs，主要是因为我无法忍受使用IDE。 对于像Groovy，Ruby和Python这样的dynamic语言来说，我不认为IDE真的会带来任何好处，因为没有任何地方可以生成代码，也不需要编译。 也许尝试一下sans IDE一段时间，看看事情是否更顺利？
所以，是的，我认为Grails是值得的。 他们已经完成了尽可能快的工作，而Grails和Groovy团队都非常专注。
当他们完成eclipse插件时，这将是值得的。 越快越好，我说。 在这种情况发生之前，试图向我的老板推销Groovy并不简单。
在开始使用Grails之前，我是Eclipse用户。 很快就显然不会削减它。 所以我尝试了Intellij和NetBeans。 当时Intellij就Groovy和Grails而言更好。 不过，NetBeans是免费的，这对我来说已经足够了。 从那时起，所有三个都有新版本或新的插件发布。 由于Intellij的成本，我仍在使用NetBeans。 随着Spring Source收购G2One，其中一个预期是在Eclipse中更多的支持Groovy和Grails。 这对于更多的采用是必要的。
使用Grails来开发一个新项目非常棒。 企业Java包的大部分已经不再需要了。 我可以想象，尝试移植一些东西是很困难的，因为直到你理解了框架的优缺点之后，很难有效地利用它。 我们承诺，在Grails 1.1中，JSP支持会变得更容易，我不知道在尝试构build新框架的时候使用beta版本是个好主意。 新版本的testing也经过了重大修改。 如果时间允许，你可以考虑等待1.1版本的发布。
如果您有机会在从头开始项目的时候尝试在不同的IDE中使用Grails，我想您会从另一个angular度看待它。
我发现Grails的最大优点是我不必再关心数据库了 – 模式是自动创build/更新的，持久性在很大程度上是为我完成的（不再需要编写SQL查询）。 这是一个巨大的安慰。 另一件相当好的事情是，一旦你在控制器和视图的模板上下定论，添加新的域对象是非常快的。 尽pipe我怀疑你至less会对你的观点做出持续的改变，但是回到现有的观点上来。
至于IDE – 似乎IntelliJ是最好的select，但我很高兴使用Netbeans 6.5。 我使用MyEclipse进行所有其他开发，但Netbeans现在只有更好的Grails支持。
我刚刚开始在一个新的项目中使用grails …不必编写任何xml文件，但仍然有Spring和Hibernate的力量是真正令人惊叹的。
尽pipeIDE使用IntellijIDEA，但实际上我通过IDE发现了Grails（虽然我可能会有偏见，但是我讨厌 eclipse）。
完全。 有那么多的Java框架，对于新手而言，该框架是相当高的，而且这是Grails的一个certificate，它能够在如此拥挤的空间中站稳脚跟。
它仍然有一些尖锐的边缘，但这些只是一个时间问题之前，他们被淘汰，底层项目是非常值得的。
对于您的应用程序types，Grails可能会很大（基于它在第一次初始化时创build的大量文件以及所需的资源）。 如果你正在寻找简单的东西，Grails可能不是你正在寻找的东西。 如果你正在寻找一些简单而有效的工具，那么我认为django可以很好的完成你的工作。 看看如何从它的教程创build一个CRUD应用程序是多么简单（它需要多less文件）。 从这里开始，随着您的需求和需求的增长，您的应用程序可以（相对）轻松扩展。
我不确定他们能否让Grails成为你所知道的。 而正确的意思是说明所有的细节（小的和大的），最终使它感觉脆弱脆弱。 我甚至不确定是否有一个真正的开发团队（意味着超过2人）。
每一次我迭代我的Grails项目的一个特性，尝试改进一些东西，它是一样的工作stream程：一切都崩溃了，然后是一百个“谷歌”testing周期，然后你找出你不能做的原因你想要什么，你做了别的什么。
最后，你很沮丧，因为你甚至不想触摸任何运行的东西。 而事情不好，你放弃他们！
我正考虑通过JRuby切换到Rails。 这可能是两全其美的：一个function强大的Web框架，拥有一个活跃的大型社区，一个专门的开发团队，一个不基于像Spring或Hibernate这样有问题和复杂的框架的平台，一个快速和雄心勃勃的发布周期。 而JRuby坦率地说，我的背包里有这么多的Java资产，我不能把它扔掉。
如果你的专长是用Java写的， 您应该看看Play Framework – 这是一个受Ruby on Rails启发并具有很短开发周期的Web框架 – 只需保存您的Java源文件并更新您的Web浏览器即可。 如果你想尝试另一种语言，Play Framework有一个模块，可以让你使用Scala。
我喜欢Play Framework，因为它很容易理解，性能也很好。 如果需要，也可以使用JPA和Hibernate作为ORM层。
