Grails（现在）值得吗？
我知道这是重复的 ，然而，自从一年前问这个问题以来，Grails世界已经有了相当大的发展，就像Eclipse支持的IDE一样，所以请不要盲目地closures它。
我认为答案是肯定的，并且已经开始使用Grails 1.2.0开发一个新项目，并且调用了STS Eclipse Integration的Groovy / Grails部分。
我认为这个问题值得在Grails进化一年后重新审视，答案肯定是混合的。
所以，作为一个有经验的Java Web开发人员，我有这些问题，并希望我的假设受到挑战：
- Grails现在是否值得与Ruby相提并论？
- 它克服了它的越野车的开始？
- 这是否真的赋予了快速发展的好处？ （我承认我现在正在挣扎，我已经超过了广泛的基线configuration，使我的定制应用程序不是列表和面向页面）
- 它是否适用于真实世界的生产应用程序？ （感觉很重）
- Eclipse插件是否比它更好，适合用途？ （我想还没有）
谢谢
编辑：我正在学习，因为我去，我有几个重要的抱怨生活与框架 – 而不是框架能力本身。 我join这些是因为我认为他们应该是考虑因素，是根据我的经验和意见，并可能帮助正在尝试决定是否去Grails的人。 我也可能performance出我对这个框架缺乏经验，所以这些都不是意味深长的批评。 我是一个有经验的开发人员，这是我发现的：
debugging真的很难 。 其实这几乎是不可能的，特别是作为框架中的初学者，这是你最需要可靠debugging器的朋友。 我已经花费了更多的时间比我应该跟踪代码的某些部分的语法错误的问题来处理引起堆栈中某处的静默失败的域字段。
logging是非常可怕的 。 你有两种模式，“没有用的”和“无用的东西”。 我的debugging日志是单页请求后128Mb，并没有包含任何关于我的错误。 在我看来，整个伐木问题需要在框架内重新考虑。
STS Eclipse IDE具有边际价值 。 除语法高亮之外，它没有多大用处。 你不能debugging代码，所以它是一个荣耀的编辑器。 代码提示是不完整的，就我所知，根本没有GSP支持。 它也是我的桌面上最慢的Eclipse插件 – 启动大约2分钟。 这是令人震惊的缓慢。 我已经恢复到一个文本编辑器（你会注意到所有的在线教程video也是这样）和一些自定义的语法高亮。
我对演出有一些严重的担忧 。 有点言之过早，但我已经发现自己调整数据库，因为hibernate。 也许这是可以预料的，但我真的必须保持我的领域模型简单的约定，以产生性能的查询。
最后一个，约定你的逻辑域模型和你的物理数据库模型应该是相同的，这不是一个明智的默认，在现实世界中不太可能是这样。 我知道你们可以将两者分开，但是这会造成一定程度的复杂性，如果这些惯例被延长，我认为这是可以避免的。 关于构图的文档不足，以及在实践中需要做什么 。
我已经使用Grails超过4个月了，我将尝试给你我个人对Grails及其可用性的感受。
Grails现在是否值得与Ruby或其他自己的版本进行比较？
当然，答案不是“是”或“否”，而是取决于 。 这取决于你的要求（你是否需要在Java世界？），也可以根据你的喜好（你喜欢面向领域的开发，你更喜欢Groovy …）？ 不过，我可以回答说，Grails是Rails的一个严重的替代品。 我相信不pipe你的Rails应用是什么，你也可以用Grails来完成。 但根据项目的性质，可能需要更多或更less的时间。 同样，如果你熟悉Rails，但不熟悉Grails，Rails是更安全的select。
它克服了它的越野车的开始？
是的 。 如果你看看我最初的消息（在这个网站或其他网站上），我抱怨Grails错误很多。 但是，您只需要记住Grails在边缘有点粗糙（比如，不要过多使用域inheritance），并且一旦熟悉了框架，就不会遇到太多不好的惊喜。 我并不是说Grails不是越野车。 它肯定比Rails更多。 而且，它比越野车更有用 。 一个build议是： 尽可能less的插件 。 因为他们中的许多人都是越野车，有些人彼此不兼容。 所以，除非你确定grails插件是最新的，非侵入性和testing（自己），否则不要包含grails插件。
这是否真的赋予了快速发展的好处？
是的 。 你几乎不需要处理DBdevise。 由于使用了Convention over Configuration，所以从一开始几乎完成了configuration。 您的应用程序很容易维护。 我看到的唯一缺点是前端开发并不像其他技术（如Rails或ASP）那么丰富，
它是否适用于真实世界的生产应用程序？
我不能说，因为我仍然没有去我的网站生活，但我很自信，因为sky.com使用Grails和网站吸引大量的stream量 – 每天约700万的页面浏览量 。 性能再次取决于您的应用程序体系结构和devise决策。
Eclipse插件是否比它更好，适合用途？
不知道。 我正在使用IntelliJ，但是根据我在Grails领域看到的抱怨信息，我想这比一年前还好。
我希望它有帮助。
最近开始了一个Rails项目，一直在用Grails做一些东西。
我用Rails的主要事情是有很多东西是完全不透明的开发（我讨厌），这往往会增加，当你开始添加更多的插件/发电机/库 /等，因为为了将它们你将需要修补一些东西。 你会觉得rails + plugins只是一个巨大的DSL hack，如果你使用了一些错误的plugins +版本的组合，就会开始崩溃。
在Grails中 ，虽然生态系统要小得多，但一切都趋于一致。 DSL方法并不是很常用，而且通过使用传统而又枯燥的devise（我的意思是使用类，接口等来代替DSL），了解pipe道工程的工作原理要容易得多。
做一对一的比较，这是如何进行的：
- 语言实现 ：我更喜欢Ruby而不是Groovy，虽然我不太了解Ruby。 Groovy感觉像是一个善意的糟糕的实现语言，其中一些特性被焊接在语法之上。 我指的是一些特殊的类，似乎只是为了让一些黑客。
- 框架特点 ：Rails在这一个领域遥遥领先。 你可以通过几种方式configurationRails的大部分方面（例如：布局，模板，css / js包装器，validation，testing框架等）。 Grails在这方面比较落后，尽pipe对大多数用例来说它足够灵活。
- 插件 ：Rails有很多插件可以被看作是一个祝福或噩梦。 有些插件没有维护，有些插件没有很好的使用，还有很多的插件。 我正在学习使用最基本和最常用的插件（authlogic，haml等）。Grails有很好的基础插件（授权/authentication，ORM等）以及一些小型插件
- testing ：Rails有很多testing的方法，但这不一定好。 有些testing框架对于一些插件来说效果不好，等等。Grails的testing插件比较less，但是他们又倾向于更好地集成一些主要的插件（因为没有太多的插件可以集成）
- 数据库 ：Grails胜利。
- 我preferebuild模我的领域类而不是黑客我的数据库。
- Hibernate（在底层使用）距Rails的对手还有几年的时间。 虽然有Rails的数据映射器（与Hibernate比ActiveRecord更类似），但我觉得还不够成熟。 Grails也通过插件进行迁移。
- 你有Hibernate（JBosscaching，EhCache等），可以提高你的performance，通过屋顶伟大的cachingimpls
- 图书馆 ：我觉得Ruby有很多像NoSQL或云服务这样的新类库，而Java有像Excel处理这样的旧类似的库。 不要忘记，Java库通常比Ruby更快
- 前沿 ：Rails更多的炒作，转化为拥有更多的资源。 这意味着如果你想将MongoDB或Riak与Rails集成，那么已经有一个很好的变化，那就是已经有人做了。 Grails是滞后的，主要是因为它不那么stream行，所以社区往往把重点放在解决日常问题，而不是像NoSQL等所有的stream血事件
这是一个例子：
- 大多数grails插件以模型和/或服务的forms生成代码。 其余通常由图书馆处理。 你可以检查模型/服务代码，看看它做了什么，并改变它。
- 大部分的Rails插件通常都和Rails API挂钩，这意味着你最终调用一些函数或者包含一些模块，然后使用插件自己的DSL。 当它工作的时候 ，这个工作非常好，但是当它破坏的时候，它会变得很糟糕，最终你不得不修补一些东西，或者安装一个不同的插件或者插件版本。 我猜测一个更老练的Rails开发人员对此更加舒适，但我不是。
结论：
- 如果你想要stream血的边缘，不要介意一些偶尔的修补，有利于大型社区和/或不介意使用ActiveRecord风格的数据库，使用Rails 。 此外，Ruby作为一种语言是非常优雅的
- 如果您喜欢使用类接口devise而不是DSL，那么您更喜欢通过模型build模您的应用程序，不需要精致的function，并且熟悉Java生态系统，可以使用Grails
这是非常值得的！
我们在几个项目中使用Grails，所有这些都取得了巨大的成功，原因如下：
-
简单 – 这是我们使用过的最简单的框架之一
-
遗留代码重用 – 我们所要做的就是获取我们的遗留代码并将其放在lib或src文件夹中，然后完成。 对我们很好。
-
传统的数据库结构 – 如果您想要在传统数据库上生成数据可视化，这是一个很棒的工具。
现在，关于生存能力：
-
错误：自1.1版以来，我们没有遇到太多的bug（版本1.0对我们来说太麻烦了）
-
工具：Netbeans在这方面确实有所改进，但它甚至没有像Intellij IDEA（很棒的支持！）这样的其他工具。 Eclipse也是如此。
-
可移植性：我们的项目从来没有遇到过单一的问题。
现在，我们已经有六个Grails应用程序在生产，而Grails不同于java框架，需要一些学习时间，因为我们已经使用了敏捷技术，所以它已经得到了回报。 细节：
- 我们使用IntelliJ。 这不是非常昂贵，几个星期后我们已经偿还了。
- 对于所有dynamic语言代码，自动化testing，持续集成和重构是必须的。 如果您已经在使用TDD或至less有一个体面的testing代码覆盖率，那么它不会增加任何额外的工作。
- Hibernate默认使用Grails，但是您可以使用其他持久性框架。 目前有5个持久性插件可用
- 在Graeme Rochers看来，logging显然不是一个问题，而是稳步提高。 我没有遇到没有logging错误的问题，但是（您必须确保在代码中正确地捕获exception）
- debugging显然不在雷达上（但这并没有改善）。 无论如何我们不依赖于debugging。
这就是说，与所有新技术一样，我build议制作原型，代码评论，结对编程，也可以使用一些咨询。
这是非常值得的。 我已经使用了一年多了，并喜欢它。 我曾经回避这些types的rad工具，但它改变了我的工作方式。 在1.2版本中，通过更好的堆栈跟踪信息（特别是对于GSP），它变得更好了。
我唯一遇到的问题就是hibernate，它是caching，这实际上不是grails问题。 即使那些我不喜欢冬眠的人，Grails对GORM的包装方式对我来说也是一件艺术品。 标准closures方面是非常好的工作。
我还没有find熟悉Grails和Rails的人，并且喜欢Grails。
如果你们都知道，那么你几乎肯定更喜欢Rails。
对于害怕平台变化的Java开发人员来说，Grails通常会有所帮助
在这种情况下，我认为JRuby可能是一种更好的方法，对陈旧的jvm采用敏捷方法。
在最近使用Grails进行项目的时候，我想和标准的J2EE应用程序开发人员分享我们的经验。
这是否真的赋予了快速发展的好处？
当然，它的确如此。 即使脚手架路线早，常规被自己的需要所覆盖，启动时间也很短，因为我们不必关心许多不同的技术。 这种轻便使我们不仅工作更快，而且更精确，更清洁。
编写标签从未如此简单 – 而在JSF中，我们首先仔细考虑是否值得付出努力，而用Grails，我们只是这样做。 testing驱动并实现高覆盖率也是相当容易的，尽pipe不同的testing用例和嘲讽策略有时是不一致的和错误的。
从Java到Groovy的切换是一件非常愉快的事情，我们喜欢列表和地图文字，闭包，build设者，抛弃我们在Java中的锅炉板“映射”实现，并写出紧凑，有意义和专注的代码。
什么减慢了开发速度是不是那么完美的IDE支持，这也适用于我们使用的IntelliJ插件。 那些分散在不同地方的糟糕的，常常是旧的，甚至是错误的文件（阻止“search结束”的承诺）也正在迅速发展。 所以我们经常不得不退回到源代码阅读 – 随后被底层的Spring类层次结构所吓倒。
debugging真的很难。 我从来没有发现这是一个大问题。 您可以附加一个debugging器，并通过代码，或将一些println / logs加载到代码中，以确定发生了什么事情。
logging是非常可怕的。 我同意堆栈跟踪通常提供4页的无用信息，偶尔的信息。 然而，为这样一个真棒框架付出的代价是很小的。
STS Eclipse IDE具有边际价值。 Eclipse对Grails的支持很差。 如果可行的话使用IntelliJ。 我是一个吝啬鬼，但如果我的公司允许我，我会很乐意为IntelliJ支付现金。
从早期的1.0-beta版开始，我一直在使用Grails，如果你来自Java商店，我只能推荐你认真考虑Groovy / Grails。
如果您是Java商店，并考虑Ruby Rails，请停下来 – 去Grails。 如果Grails不适合你，那么你总是可以启动Rails。
我将在近十个应用中分享我使用Grails的3年经验。 我无法比较Ruby on Rails，所以我会回答你的其他问题。
它克服了它的越野车的开始？
- 是的，它有。 我在Grails 2.0.4 / 2.2.4上遇到过一些Grails的bug。
这是否真的赋予了快速发展的好处？
- 学习起来非常简单，容易开发，从来没有见过任何对Java世界有深入了解的人花费不止一个星期的时间来了解基础知识。 也容易维护。 而且你不必担心你的数据库 – 只要确保你是麦克
Eclipse插件是否比它更好，适合用途？
- select你的IDE非常仔细。 Eclipse帮助了我很多，但它崩溃，并导致比它应该更多的麻烦。 我去了IntelliJ，在试用月份，这似乎是一个更好的select。 最近我一直在使用Sublime Text，一些插件和旧的命令行。 例如，在特殊情况下，我只能使用它的debugging器。
它是否适用于真实世界的生产应用程序？
- 这是一种沉重的。 在写模型之前，先研究一下你的deviseselect。 对Grailsdevise进行大量的研究。 我两年前所做的大部分事情，我现在可以意识到如何让自己变得更好，因为我更有经验。 它处理现实世界的生产应用程序，但取决于你使Hibernate的错误真的很头疼。
Grails Eclipse插件是废话。 它毫无理由地崩溃，并没有真正支持Groovy的灵活性。 据传NetBeans和IntelliJ要好得多，但我还没有尝试过。
它执行吗？ 当然是的。 即使Ruby on Rails也能执行，只要你在这个问题上投入足够的服务器。 不过，我不知道Grails如何与各种Java框架进行比较。
这是否真的赋予了快速发展的好处？ 那么，我仍然错过了很多好的Ruby / Rails的东西。 它不会自动识别Date和Enum请求params（然后，Rails在date中也有一些问题），TimeCategory应该是标准configuration的一部分，但不是。 但是也有很多东西需要非常less的configuration。
这并不是Rails所在的地方（我特别期待Rails 3），但与许多Java框架相比，合作起来更令人愉快。 即使如此，表面以下的魔法也比Rails更深入。 例如，Constraints系统是非常强大的，但是它build立在一个庞大的Spring层面之上，如果你想以相同的方式使用相同的function，那么这个系统就非常不灵活。 input法更容易颠覆，IME。
这值得么？ 是。 这是比别的更好的select吗？ 那要看。
我build议你自己试试。 我喜欢Grails的灵活性和开发速度。 但是，正如你所看到的，其他人的经验不一样。 我希望能够使用Java平台为我的客户开发快速应用程序，并且我发现Grails能够很好地为我们工作。
我也发现前端的开发非常灵活。 我也认为你需要使用常识，并仔细select你的插件。 我坚持由springource支持的插件。
以我的经验，Grails在桌面上带来了一些非常有吸引力的function，这绝对是值得学习和使用的。
- 敏捷性 – 我们在传统J2EE项目中花费数周时间来完成的任务通常是使用grails插件系统的一天。 事情就像ajax，jQuery的UI，acegi，宁静的执行，调度系统和他们很多
- 在JVM上运行，这减轻了学习一些其他运行时系统及其特性的需要
-
Java像语法和groovy语法糖。 像世界上最好的一样。 您可以立即从Java开始，而不是学习像Ruby这样的新语言的语法，然后慢慢地转向Groovy语法，这个语法是健壮，简单和直观的
对于项目经理来说，除非出于某种原因（不要使用Grails）有强制性的理由（阻力来自于更高层，采用新技术或什么的），否则我不认为Grails不能被使用的原因或最less尝试。
为了回答关于debugging的问题，并不难。 如果使用Netbeans IDE，debugging很容易。 这使我想再提一点。 经过几次对所有IDE的实验，我们发现Netbeans是最适合做这项工作的。 它更好地支持代码完成，语法高亮和debugging等。在我看来，STS不够好。
Eclipse插件是否比它更好，适合用途？
过去一年来，它已经有了明显的改善。 12月，我参加了伦敦的Groovy＆Grails交易所。 关于已logging的Eclipse / SpringSource STS中的Groovy＆Grails集成有一个很好的讨论，请参阅video 。
从我的angular度来看，Eclipse获得了很多的理由。 目前IntelliJ似乎略有提前，但在未来几个月内可能会有所改变。
关于eclipse插件，现在还在继续，但是你可以使用Spring Source（SpringSource Tool Suite）的eclipse版本，
http://www.springsource.com/products/sts
与以前的插件版本相比，它相当不错，而且由于Spring Source已经收购了负责grails和groovy的公司，所以你可以预期STS会变得更快
就我个人而言，我学习了RoR，并将其用于一些家庭项目，但后来转而使用Grails，主要是因为它运行在JVM上，所以我希望能够利用大量的Java性能/性能分析程序，这有助于识别代码中的瓶颈在它们成为问题之前。
一般来说，我没有发现RoR和Grails使用的IDE的质量差别太大。 虽然，公平地说，我在Linux上编程，并没有尝试使用TextMate进行RoR开发。 当我使用RoR时，我使用了Netbeans。
现在我正在使用STS进行编程，我发现使用Grails很愉快，尽pipe我仍然发现可以使方法检测/完成更好地工作。
我是一个全职的Java开发人员，但为我的爱好项目使用铁轨。 我们在一年前的工作中评估过Grails项目。 我对Grails的经验让我感到有些失望，这就是我开始研究rails的原因。 使用我的印象是，即使groovy作为一种语言并不遥远ruby，轨道提供了一个显着改善的经验比grails。 很简单，轨道似乎解决了更多的现实世界的问题，特别是当你考虑可用的好的gem数量。 我正在考虑像提供search，版本控制，rss，非crud应用程序，与云服务的集成等等。我感觉到grails是围绕rails 1.x的水平。 到本月底，应该已经发布了第三轨。 我们实际上已经决定在工作中使用导轨。 最终，Grails更容易为Java开发人员所接受，但最终还是缺乏完善来覆盖更广泛的项目需求。
我会说不。 对于大多数用途来说，它太臃肿了，特别是如果你只是想做一些原型的话。 我们并不需要所有这些代码，所有这些与grails捆绑在一起的依赖项，以便构build一个Web应用程序。 每当你想放出一个Web应用程序，你不需要弹簧。 在将一个充满了依赖的整个世界添加到你的堆栈之前，先看看你正在尝试完成什么。 我认为重要的是要知道你的应用程序包含什么。
我build议看一下像ratpack这样的东西，它比较轻，几乎就像是ruby的sinatra。
我想指出两个更多的考虑，内存使用和就业市场。 Grails应用程序占用大量内存，特别是在开发模式下，例如600 Mb的中型应用程序。 当在生产模式下部署时，例如Tomcat中的war文件，使用量可以是大约500 Mb。 这部分是使用Javainheritance的。
就职业市场而言，据我所知，与Django和Ruby on Rails相比，Grails程序员在职位空缺公告方面的需求不大。
从我的经验到2013年底。
优点
- 当你使用很less的插件，并且限制了一组Grails没有，而且从来没有，这是一个非常顺利的开发经验
缺点
- 刷新（F5）总是一个问题。 而这是最烦人的。 出于某种原因，我不得不在每次3-4次刷新时重新启动服务器。 有一个众所周知的重启bug： question1 ， question2 ，虽然很less发生。
- 语言级别的错误。 当我使用静态内部类时，我总是需要在更改时重新启动服务器。 虽然build筑没有问题，但语言使用对我来说是有限的
- 启动时间，编译时间，应用程序大小（一个小应用程序70兆），内存使用情况
- 只有远程debugging，IDEdebugging非常不稳定
它克服了它的越野车的开始？
这仍然是可怕的。 我不知道他们的开始，但从Grails 2到Grails 3的迁移仍然是噩梦，他们正在打破更多的解决scheme。
这是否真的赋予了快速发展的好处？
我花了一个小时让Grails的testing在控制台输出了一些东西（即使不是开箱即用），即使在Java中，也不会花费这么多的时间输出testing结果。
它是否适用于真实世界的生产应用程序？
我还不知道一个正在与Grails合作的着名公司。
Eclipse插件是否比它更好，适合用途？
我不知道为什么有人仍在使用Eclipse，但对Grails 3的IntelliJ支持是无法使用的。
所以，回答主要问题：
Grails（现在）值得吗？
如果您无法承担Microsoft Access许可证，也许。 对于真正的项目，我会远离Grails。 事实上，这只是一个死胎。
