Grails（现在）值得吗？[关闭]

我已经使用 Grails 4 个多月了，我将尝试给大家介绍我对 Grails 及其可用性的个人感受。

Grails 现在值得吗，而不是 Ruby 或其他你自己的版本？

当然，答案不是“是”或“否”，但这取决于。这取决于你的要求（你需要进入Java世界吗？），也取决于你的偏好（你更喜欢面向领域的开发，你更喜欢Groovy吗......）？ 但是，我可以回答说，Grails 是 Rails 的重要替代品。我相信无论你的 Rails 应用程序是什么，你都可以用 Grails 来完成。但根据项目的性质，可能需要或多或少的时间。同样，如果你熟悉 Rails 但不熟悉 Grails，那么 Rails 是更安全的选择。

它是否克服了错误的启动？

是的。如果你看一下我最初的消息（在这个网站或其他网站上），我抱怨了很多关于Grails的错误。但是，你只需要记住，Grails在边缘有点粗糙（例如，没有过多地使用领域继承），一旦你熟悉了框架，你就不会遇到太多不好的意外。我并不是说 Grails 没有 bug。它肯定不仅仅是 Rails。而且，它比越野车更有用。对此的建议是：使用尽可能少的插件。因为它们中的许多都是有问题的，有些彼此之间不兼容。因此，除非您确定 grails 插件是最新的、非侵入性的并且经过测试（由您自己）使用，否则不要包含 grails 插件。

它真的能带来快速发展的好处吗？

是的。您几乎不需要处理数据库设计。由于约定优先于配置，几乎从一开始就为您完成了配置。您的应用程序易于维护。我看到的唯一缺点是前端开发不如其他技术（如 Rails 或 ASP）丰富

它是否适用于实际的生产应用？

我不能说，因为我仍然没有上线我的网站，但我非常有信心，因为 sky.com 正在使用 Grails，并且这些网站吸引了大量的流量 - 周围 每天 700 万页面浏览量。同样，性能很大程度上取决于您的应用程序体系结构和设计决策。

Eclipse 插件是否比以前更好并且适合用途？

不知道。我正在使用 IntelliJ，但根据我在 Grails 领域看到的抱怨消息，我想它并不比一年前好多少。

我希望它有所帮助。

我是一名全职的 Java 开发人员，但在我的爱好项目中使用 rails。一年前，我们评估了一个项目的圣杯。我对 grails 的体验让我感到有点失望，这就是我开始研究 rails 的原因。使用这两种语言后，我的印象是，尽管 groovy 作为一种语言并不落后于 ruby，但 rails 提供了比 grails 显着改进的体验。很简单，rails 似乎可以解决更多现实世界的问题，尤其是当你考虑到可用的好宝石数量时。我正在考虑提供搜索、版本控制、rss、非 crud 应用程序、与云服务的集成等。 我的印象是 grails 大约是 rails 1.x 的水平。到本月底，rails 3 应该已经发布。实际上，我们现在已经决定在工作中使用导轨。最后，对于Java开发人员来说，grails更容易上手，但最终缺乏涵盖更广泛的项目需求的改进。

Eclipse 插件是否比以前更好并且适合用途？

在过去的一年里，它肯定有了很大的改善。12月，我参加了在伦敦举行的Groovy&Grails交流会。关于Eclipse/SpringSource STS中的Groovy&Grails集成，有一个很好的演讲，请看视频。

从我的角度来看，Eclipse 取得了很大的进展。目前，IntelliJ 似乎略微领先，但这种情况可能会在未来几个月内发生变化。

Grails Eclipse插件是废话。它无缘无故地崩溃，并且并不真正支持 Groovy 的灵活性。有传言说 NetBeans 和 IntelliJ 要好得多，但我还没有尝试过。

它有性能吗？当然可以。即使是 Ruby on Rails 也能运行，只要你投入足够的服务器来解决这个问题。不过，我不知道Grails与各种Java框架相比如何。

它真的能带来快速发展的好处吗？好吧，我仍然缺少很多好的 Ruby/Rails 东西。它不会自动识别 Date 和 Enum 请求参数（话又说回来，Rails 在 Dates 方面也存在一些问题），TimeCategory 应该是标准配置的一部分，但不是。但是也有很多东西需要非常少的配置。

它不是 Rails 所处的位置（我特别期待 Rails 3），但它比许多 Java 框架更令人愉快。即便如此，表面之下的魔力比 Rails 要深得多。例如，Constraints 的系统非常强大，但建立在一大层难以穿透的 Spring 之上，如果你想以稍微不同的方式使用相同的功能，它真的很不灵活。Rails 更容易被颠覆，IME。

值得吗？是的。这是比其他东西更好的选择吗？那要看情况。

这是非常值得的！

我们在几个项目中使用了Grails，这些项目都取得了巨大的成功，原因如下：

• 简单 - 这是我们用过的最简单的框架之一

• 遗留代码重用 - 我们所要做的就是获取遗留代码并将其扔到 lib 或 src 文件夹中，然后就完成了。对我们来说很棒。

• 旧数据库结构 - 如果您想在旧数据库上生成数据可视化效果，这是一个很棒的工具。

现在，关于可行性：

• 错误：自 1.1 版以来，我们没有遇到太多错误（1.0 版对我们来说太有问题了）

• 工具：Netbeans 在这方面确实有所改进，但它甚至无法接近 Intellij IDEA 等其他工具（强大的支持！Eclipse 也是如此。

• 可移植性：我们的项目从未遇到过任何问题。

我建议你自己试试。我喜欢 Grails 的灵活性和开发速度。但是，正如您所看到的，其他人的经历有所不同。我希望能够使用 Java 平台为我的客户开发快速的应用程序，我发现 Grails 对我们来说非常有效。

我还发现前端的开发非常灵活。我还认为您需要使用常识并仔细选择您的插件。我坚持使用springsource支持的插件。

关于eclipse插件，它仍在开发中，但你可以使用Spring Source（SpringSource工具套件）中的eclipse版本

http://www.springsource.com/products/sts

与之前的插件版本相比，它已经相当不错了，而且由于 Spring Source 已经收购了负责 grails 和 groovy 的公司，因此您可以预期 STS 会很快变得更好

这是非常值得的。我已经使用它一年多了，很喜欢它。我曾经回避这些类型的 rad 工具，但它改变了我的工作方式。在 1.2 版本中，它变得更好，具有更好的堆栈跟踪信息（特别是对于 GSP）。

我在扩展方面遇到的唯一问题是休眠和缓存，这真的不是圣杯问题。即使是那些我不喜欢冬眠的人，圣杯用 GORM 包装它的方式对我来说也是一件艺术品。标准闭合方面非常值得使用。

我们现在有六个 Grails 应用程序在生产中，虽然 Grails 与 Java 框架不同，需要一些学习时间，但它已经得到了回报，因为我们使用了敏捷技术。详：

• 我们使用 IntelliJ。它不是很贵，几周内就为我们偿还了。
• 自动化测试、持续集成和重构是必须的，就像所有动态语言代码一样。如果你已经练习了TDD，或者至少有一个不错的测试代码覆盖率，那么它不会增加任何额外的工作。
• Hibernate 默认是 Grails 附带的，但你可以使用其他持久性框架。目前还有 5 个持久性插件可用
• 在Graeme Rochers的心目中，伐木显然不是一个问题，但它已经稳步改善。不过，我没有遇到过未记录错误的问题（您必须确保在代码中正确捕获异常）
• 调试显然不在雷达上（但这并没有改善）。无论如何，我们不依赖调试。

也就是说，与所有新技术一样，我建议制作原型、代码审查、结对编程，也许还会使用一些咨询。

最近在一个项目中使用了 Grails，我想分享一下我们与标准 J2EE 应用程序开发相比的经验。

它真的能带来快速发展的好处吗？

当然，确实如此。即使很早就离开了脚手架路径，并且根据自己的需求覆盖了惯例，启动期也非常短，因为我们不必关心许多不同的技术。这种轻量化不仅使我们的工作速度更快，而且更精确、更干净。

编写标签从未如此简单——在 JSF 中，我们首先考虑是否值得付出努力，而在 Grails 中，我们只是这样做。测试驱动和实现高覆盖率也变得非常容易，尽管不同的测试用例和模拟策略有时不一致且有问题。

从 Java 切换到 Groovy 是一种极大的乐趣，我们喜欢使用列表和映射文字、闭包、构建器，抛弃我们在 Java 中的样板“映射”实现，并编写紧凑、有意义和集中的代码。

减慢开发速度的是不太完美的 IDE 支持，这也适用于我们使用的 IntelliJ 插件。散落在不同地方的糟糕的、通常是旧的甚至错误的文档（挫败了“搜索结束”的承诺）也阻碍了快速开发。因此，我们经常不得不回退到源代码阅读上——随后被底层的 Spring 类层次结构吓坏了。

根据我的经验，Grails带来了一些非常吸引人的特性，这绝对值得学习和使用。

• 敏捷性 - 我们过去在传统的 J2EE 项目中需要花费数周时间才能实现的东西，通常只需一天才能使用 grails 插件系统。像ajax、jquery ui、acegi、restful实现、调度器系统等等
• 在 JVM 上运行，这减轻了学习其他运行时系统及其特性的需要

• 像 Java 一样的语法和时髦的语法糖。就像两全其美一样。你可以立即开始使用 Java，而不是学习像 Ruby 这样的新语言的语法，然后慢慢地，你可以转向健壮、简单和直观的时髦语法

  对于项目经理来说，除非出于某种原因（来自上级的阻力、采用新技术或其他原因）有令人信服的理由“不使用”圣杯，否则我看不出有任何理由不能使用或至少尝试过圣杯。

要回答有关调试的问题，这并不难。如果使用 Netbeans IDE，则调试很容易。这让我还要提一点。在对所有 IDE 进行了几次实验后，我们发现 Netbeans 最适合完成这项工作。它对代码补全、语法高亮和调试等有更好的支持。在我看来，STS还不够好。

最近开始了一个 Rails 项目，一直在用 Grails 做一些事情。

我对 Rails 的主要事情是，有很多东西对开发人员来说是完全不透明的（我讨厌），当你开始添加更多插件/生成器/库/等时，这种情况往往会增加，因为为了将它们组合在一起，你需要修补一些东西。你会觉得 rails+plugins 只是一个巨大的 DSL hack，如果你使用一些错误的插件+版本组合，它就会开始崩溃。

对于Grails来说，虽然生态系统要小得多，但一切都趋于相对一致。DSL 方法不是很常用，通过使用传统但无聊的设计（我的意思是使用类、接口等而不是 DSL），更容易理解管道的工作原理。

进行 1 比 1 的比较，这是怎么回事：

• 语言实现：我更喜欢 Ruby 而不是 Groovy，尽管我对 Ruby 不太了解。Groovy 感觉像是一种善意的实现语言，其中的一些功能被焊接在语法之上。我指的是一些特殊的类，这些类似乎只是为了允许一些黑客攻击。
• 框架功能：Rails 在这方面遥遥领先。您可以通过多种方式配置 Rails 的大多数方面（例如：布局、模板、css/js 打包器、验证、测试框架等）。Grails在这方面落后了，尽管它对于大多数用例来说已经足够灵活了。
• 插件：Rails 有大量的插件，可以看作是祝福或噩梦。有些插件没有得到维护，有些插件不能很好地与某些功能或插件配合使用，并且有很多分支。我正在学习坚持使用基本和最常用的插件（authlogic、haml 等） Grails 为基础知识（授权/身份验证、ORM 等）提供了出色的插件，还有一些其他用于较小内容的插件
• 测试：Rails 有很多测试方法，但这不一定是好的。一些测试框架不能很好地与某些插件等配合使用。Grails 的测试插件较少，但它们往往能更好地与一些主要插件集成（因为没有那么多插件可以集成）
• 数据库：Grails 胜过。
  • 我更喜欢对我的领域类进行建模，而不是对我的数据库进行黑客攻击。
  • Hibernate（在引擎盖下使用）与Rails的对应物相差数年。虽然有 Rails 的数据映射器（它在本质上更类似于 Hibernate 而不是 ActiveRecord），但我觉得它还不够成熟。Grails也通过插件进行迁移。
  • 你有很好的Hibernate缓存实现（JBoss缓存，EhCache等），可以提高你的性能
• 库：我觉得 Ruby 有很多用于 NoSQL 或云服务等新东西的库，而 Java 有很多用于 Excel 处理等旧东西的库。不要忘记 Java 库通常比 Ruby 快得多
• 前沿：Rails 更是炒作，这意味着它背后有更多的资源。这意味着，如果你试图将MongoDB或Riak与Rails集成，那么已经有人做了一个很好的改变。Grails是滞后的，主要是因为它不那么流行，所以社区倾向于专注于解决日常问题，而不是使用所有前沿的东西，如NoSQL等

下面是一个示例：

• 大多数grails插件以模型和/或服务的形式生成代码。其余的通常由库处理。您可以检查模型/服务代码，查看其功能并对其进行更改。
• 大多数 Rails 插件通常与 Rails API 挂钩，这意味着您最终会调用某个函数或包含某个模块，然后使用插件自己的 DSL。这在工作时效果很好，但是当它坏了时，它就很可怕了，你最终不得不修补一些东西，或者安装不同的插件或插件版本。我猜一个更有经验的 Rails 开发人员对此更满意，但我不是。

---

结论：

• 如果你想要前沿，不介意偶尔打补丁，偏爱一个大型社区和/或不介意使用ActiveRecord风格的数据库，那就选择Rails吧。此外，Ruby 作为一种语言非常优雅
• 如果你更喜欢类接口设计而不是 DSL，更喜欢通过模型来建模你的应用程序，不需要精致的功能并且熟悉 Java 生态系统，那么请选择 Grails

我还没有找到一个既精通 Grails 又精通 Rails 并且更喜欢 Grails 的人。

如果你对两者都很了解，那么你几乎可以肯定更喜欢 Rails。

Grails 通常吸引那些害怕平台变化的 Java 开发人员。

在这种情况下，我认为 JRuby 可能是在老化的遗留 jvm 上采用敏捷方法的更好方法。

就我个人而言，我学习了 RoR 并将其用于一些家庭项目，但后来转向了 Grails，主要是因为它运行在 JVM 上，因此我希望利用大量的 Java 性能/分析程序，这应该有助于在代码中的任何瓶颈成为问题之前识别它们。

总的来说，我没有发现 RoR 和 Grails 使用的 IDE 质量有太大差异。虽然，公平地说，我在 Linux 上编程，还没有尝试过 TextMate 进行 RoR 开发。当我使用 RoR 时，我使用的是 Netbeans。

现在我正在使用 STS 进行编程，并且发现与 Grails 一起使用很愉快，尽管我仍然发现方法可以更好地工作。

调试真的很难。我从来没有发现这是一个大问题。您可以附加调试器并演练，也可以将大量 println/logs 粘贴到代码中以找出发生了什么。

坦率地说，日志记录很糟糕。我同意堆栈跟踪通常提供 4 页无用的信息，偶尔有一行内容丰富。然而，为这样一个很棒的框架付出的代价很小。

STS Eclipse IDE具有边际价值。Eclipse 对 Grails 的支持很差。如果可行，请使用 IntelliJ。我是一个紧箍咒，但如果我的公司允许我，我很乐意为 IntelliJ 支付现金。

我从 1.0 beta 的早期就开始使用 Grails，如果你来自 Java 商店，我只能建议你开始认真对待 Groovy/Grails。

如果你是一个 Java 商店，并且正在考虑 Ruby Rails，那就停下来——去 Grails。如果 grails 对你不起作用，那么你总是可以启动 Rails。

我会说不。恕我直言，对于大多数用途来说，它仍然太臃肿了，特别是如果你只是想制作一些东西的原型。我们不需要所有这些代码，也不需要所有那些与grails捆绑在一起的依赖项来制作一个Web应用程序。您不需要每次都要发布 Web 应用程序时就需要 spring。在向堆栈添加充满依赖项的整个世界之前，先看看您要完成什么。我认为了解您的应用程序由什么组成很重要。

我建议看看像老鼠包这样的东西，它要轻得多，几乎就像红宝石的 sinatra。

我想指出另外两个考虑因素，内存使用和就业市场。Grails 应用程序占用大量内存，尤其是在开发模式下，例如中等大小的应用程序需要 600 Mb。当部署在生产模式下时，例如 Tomcat 中的 war 文件，使用量约为 500 Mb。这在一定程度上继承自使用 Java。

至于就业市场，据我所知，与Django和Ruby on Rails相比，在职位空缺公告中对Grails程序员的需求很少。

根据我截至2013年底的经验。

优点

• 当你使用很少的插件并限制一组 Grails no-s 和 never-s 时，开发体验会非常流畅

缺点

• 刷新 （F5） 始终是一个问题。这是最烦人的。出于某种原因，我不得不在每次第 3-4 次刷新时重新启动服务器。有一个众所周知的重启错误：question1、question2，尽管它很少发生。
• 语言级错误。当我使用静态内部类时，我总是需要在更改时重新启动服务器。虽然构建没有问题，但语言使用对我来说是有限的
• 启动时间、构建时间、应用程序大小（小型应用程序为 70 Megs）、内存使用情况
• 只有远程调试，IDE调试很不稳定

我将分享我在近十个应用程序中使用 Grails 的 3 年经验。我无法与Ruby on Rails进行比较，所以我会回答你的其他问题。

它是否克服了错误的启动？

• 是的，它有。我在 Grails 2.0.4/2.2.4 上遇到了一些 Grails 错误。

它真的能带来快速发展的好处吗？

• 它非常简单易学，易于开发，从未见过任何对 Java 世界有良好了解的人需要花费超过一周的工作来了解基础知识。也易于维护。而且你不必太担心你的数据库 - 只要确保你的数据库是

Eclipse 插件是否比以前更好并且适合用途？

• 请非常谨慎地选择您的 IDE。Eclipse 对我帮助很大，但它崩溃并造成比应有的更多的麻烦。我选择了 IntelliJ，在试用月中，它似乎是一个更好的选择。最近我一直在使用 Sublime Text、一些插件和旧的命令行。我只在特殊情况下使用 IDE - 例如，使用其调试器。

它是否适用于实际的生产应用？

• 它有点重。在编写模型之前，请对您的设计选择进行大量研究。做很多关于好的Grails设计的研究。我两年前做过的大部分事情，我现在可以意识到如何让它变得更好，因为我更有经验。它可以很好地处理现实世界的生产应用程序，但根据你犯的错误，Hibernate 确实可能是一个令人头疼的问题。

它是否克服了错误的启动？

这仍然很可怕。我不知道他们的开始，但从 Grails 2 迁移到 Grails 3 仍然是一场噩梦，他们破坏的比解决的要多。

它真的能带来快速发展的好处吗？

我花了一个小时制作 Grails 的测试以在控制台中输出一些东西（它不是开箱即用的），即使在 Java 中，您也不会花费如此多的时间从测试中输出一些东西。

它是否适用于实际的生产应用？

我仍然不知道有哪家著名的公司正在用Grails构建一些东西。

Eclipse 插件是否比以前更好并且适合用途？

我不知道为什么还有人还在使用 Eclipse，但 IntelliJ 对 Grails 3 的支持是无法使用的。

因此，回答主要问题：

Grails（现在）值得吗？

如果您买不起 Microsoft Access 许可证，也许。对于真正的项目，我会远离Grails。事实上，这只是一个死产的孩子。