Grails（现在）值得学习吗？

Question

我知道这是一个重复问题，但自那个问题被问出以来，Grails世界和Eclipse的IDE支持已经取得了相当大的进展，因此请不要盲目关闭它。

我认为答案是肯定的，并开始使用Grails 1.2.0进行新项目，并尝试使用STS Eclipse Integration的Groovy/Grails部分。

我认为在一年的Grails演进之后应该重新审视这个问题，当时答案是明确的“两极分化”。

所以，作为经验丰富的Java Web开发人员，我有以下几个问题，并希望我的假设能够受到挑战：

• Grails现在是否值得使用，相比Ruby或自己开发？
• 它是否克服了起步时的错误？
• 它是否真的带来快速开发的好处？（我承认我现在正在努力完成基线配置之外的定制应用程序，这些应用程序不仅仅是列表和页面导向）
• 它是否适用于真实的生产应用程序？（它感觉很重）
• Eclipse插件是否比以前更好，并且是否能够胜任工作？（我认为还没有）

谢谢

编辑： 我在不断学习中，对使用该框架有一些显著的抱怨 - 而不是框架本身的功能。我之所以加入这些内容，是因为我认为它们应该作为考虑因素，并基于我的经验和意见，可能会帮助某些人决定是否采用Grails。我也可能显示出我对该框架的经验不足，因此这些都不是完全批评。我是一名经验丰富的开发人员，以下是我的发现：

调试真的很难。事实上，对于一个框架的初学者来说，它几乎是不可能的，这时你最需要你可靠的调试器朋友了。我花了比找到与域字段相关的语法错误在代码的某些部分所需的时间更多的时间，以跟踪导致堆栈中某处出现静默故障的问题。

记录日志真是太可怕了。你有两种模式，“没有有用的信息”和“大量无用的东西”。我的调试日志在单个页面请求后达到了128Mb，却没有包含任何关于我的错误的信息。我认为整个记录日志的问题需要在框架中重新考虑。

STS Eclipse IDE的价值有限。除了语法高亮之外，它没什么用处。你不能调试代码，所以它只是一个带有强化编辑功能的编辑器。代码提示不完善，就我所知，它根本不支持GSP。它也是我桌面上最慢的Eclipse插件——启动需要大约2分钟的时间。它非常慢。我已经回到了一个文本编辑器（你会注意到所有在线教程视频也都是如此）和一些自定义的语法高亮。

我对性能有一些严重的担忧。现在说还为时过早，但由于Hibernate，我已经开始调整数据库了。也许这是可以预料的，但我真的必须让我的域模型保持简单，以便约定产生高效的查询。

最后一个问题，逻辑域模型和物理数据库模型应该相同的想法不是明智的默认设置，而且在实际情况下很少会发生。我知道你可以将两者分开，但这会导致某种程度的复杂性，如果扩展惯例，则可以避免这种情况。关于组合和如何使其在实践中工作的文档不足，需要做什么才能使其运行起来。

- Simon

Answer 1

Yes. Grails is used by many organizations to develop and deploy real world production applications. In fact, it is built on top of the battle-tested Java ecosystem, which provides excellent performance, scalability, and security. However, like any technology, it requires proper optimization and configuration to perform well under high load. But overall, Grails is a reliable choice for building production-grade applications.

我无法确定，因为我还没有将我的网站上线，但我非常有信心，因为 sky.com 使用 Grails 并且这些网站吸引了大量的访问流量 - 每天约 700 万次页面浏览量。再次强调，性能很大程度上取决于您的应用程序架构和设计决策。

现在的 Eclipse 插件是否比以前更好，是否适合使用？

不清楚。我正在使用 IntelliJ，但根据我在 Grails 领域看到的抱怨信息，它似乎并没有比一年前更好。

希望对你有所帮助。

- fabien7474

---

我赞同关于插件的观点。你无法保证插件会为新版本的Grails进行更新。我建议你坚持使用由Grails / SpringSource支持的插件。 - Kimble

插件在Grails社区中是一个有趣的群体。如果你将插件视为黑匣子，只是用于你的应用程序，那么我认为你会遇到问题。但是，如果你将插件视为Grails社区提供给你的模板，则会更好地使用它们。 - Ben Doerr

Grails对NetBeans的支持很好。 - deamon

NetBeans或IntelliJ是Grails的首选IDE。如果你有钱，可以选择IntelliJ。 - ubiquibacon

Rails使用了5年，Groovy/Grails使用了8个月。熟悉情况下，Rails更好，但是一旦你克服了最初的学习难关，Grails也是非常可用的。与之相比，Grails感觉有点过于依赖配置文件（我真的需要为单个插件模块使用6或7个吗？），但持久层非常好用。至于IDE，使用STS 4个月，遇到了很多挫折，然后尝试了IntelliJ 4天，从此不再回头。 - railsdog

Akamai处理了sky.com 98%的流量。我不想谈论节点的正常运行时间。我已经转向使用Dropwizard。我仍然喜欢Groovy。 - barrymac

Answer 2

最近开始了一个Rails项目，之前一直在用Grails。

我对于Rails的主要问题是有很多东西对开发者来说完全是不透明的（我讨厌这个），并且当你开始添加更多的插件/生成器/库等时，这种情况会增加，因为为了将它们组合起来，你需要修补一些东西。你会感到Rails+插件只是一个巨大的DSL hack，如果你使用了一些错误的插件+版本组合，它就会开始出问题。

对于Grails而言，虽然生态系统远远较小，但所有东西都比较一致。DSL方法并没有被广泛使用，通过使用传统但单调的设计（我的意思是使用类、接口等而不是DSL），更容易理解其工作原理。

进行一对一的比较，下面是比较结果：

• 语言实现：我更喜欢Ruby而不是Groovy，尽管我不是很熟悉Ruby。Groovy感觉像是一个好意的坏实现的语言，其中一些特性是附加到语法之上的。我指的是一些特殊的类，似乎只是为了允许一些hack。
• 框架特性：Rails在这方面远远领先。你可以通过多种方式配置Rails的大多数方面（例如布局、模板、css/js打包器、验证、测试框架等）。虽然Grails在此方面滞后，但对于大多数用例来说，它是足够灵活的。
• 插件：Rails有许多插件，可以看作是一种福音或噩梦。一些插件没有维护，其他一些插件不与某些功能或插件兼容，还有许多分支。我正在学习如何坚持使用基本和最常用的插件（authlogic、haml等）。Grails有出色的基本插件（授权/身份验证、ORM等）和一些其他用于更小的东西的插件。

测试: Rails提供了很多种测试方式，但这并不一定是好事。有些测试框架与某些插件不兼容。Grails的测试插件较少，但它们往往更好地与一些主要插件集成（因为没有那么多需要集成的插件）

数据库: Grails远远胜出。

• 我更喜欢模型化我的域类，而不是在数据库上进行修改。
• 底层使用的Hibernate比其Rails的同类产品先进几年。虽然Rails也有Datamapper（与Hibernate相似），但我认为它还不够成熟。Grails还有一个通过插件实现的迁移工具。
• 你可以利用Hibernate的缓存实现（如JBoss cache、EhCache等）大幅提高性能。

库: 我觉得Ruby有很多新东西的库，比如NoSQL或云服务，而Java有许多老旧的库，如Excel处理。不要忘记，Java库通常比Ruby快得多。

前沿技术: Rails更加炙手可热，这意味着它背后有更多的资源支持。这意味着如果你试图将MongoDB或Riak与Rails集成，很有可能已经有人做过了。Grails滞后在此方面，主要是因为它不太流行，因此社区倾向于解决日常问题，而不是使用所有最新的技术，如NoSQL等。

以下是一个例子：

• 大多数Grails插件会以模型和/或服务代码的形式生成代码。其余部分通常由库处理。您可以检查模型/服务代码，看看它做了什么并进行更改。

大多数Rails插件通常会与Rails API连接，这意味着您最终会调用一些函数或包含某些模块，然后使用插件自己的DSL。当一切正常时这很好，但当出现问题时，情况就糟糕了，您可能需要修补一些内容，或安装另一个插件或插件版本。我猜更有经验的Rails开发人员对此更为熟悉，但我不是。

---

结论：

• 如果您想要最先进的技术，不介意偶尔进行修补，喜欢一个庞大的社区和/或不介意使用ActiveRecord-style的数据库，请选择Rails。另外，Ruby作为语言非常优雅。
• 如果您喜欢类接口设计而不是DSL，更喜欢通过模型来建模应用程序，不需要精致的功能并且熟悉Java生态系统，请选择Grails。

- Miguel Ping

---

我刚刚发现了你的答案。非常好的答案。非常客观。 - fabien7474

Answer 3

这非常值得！

我们在多个项目中使用Grails，在以下方面都取得了巨大的成功：

• 易用性 - 这是我们所使用过的最容易的框架之一。

• 旧代码重用 - 我们所要做的就是获取我们的旧代码并将其放在lib或src文件夹中，然后就完成了。对我们来说非常棒。

• 旧数据库结构 - 如果您想要在旧数据库上生成数据可视化，那么这是一个绝妙的工具。

现在，关于可行性：

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

• 工具：Netbeans在这方面确实有所改进，但与Intellij IDEA等其他工具相比还有很大差距（支持很好！）。 Eclipse也是如此。

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

- Kico Lobo

---

Simon，请看一下这个项目http://www.manubia.com.br 它是一个完全使用Grails完成的个人财务管理器。它表现出色。 - Kico Lobo

Simon：除非你想要开发一些实时应用，否则性能不是问题。是的，它消耗的RAM比Java应用程序多，但你可以在更短的时间内开发企业应用程序，因此你可以节省大量的人力和金钱。你可以用这些省下来的钱购买更好的服务器，仍然可以节省很多钱。 - luisZavaleta

Answer 4

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

详情如下：

• 我们使用IntelliJ。它的价格不是很贵，而且在几周内就为我们赚回来了。
• 自动化测试、持续集成和重构是必须的，对于所有动态语言代码都是如此。如果你已经实践TDD或至少有一个合理的测试代码覆盖率，那么它不会增加任何额外的工作。
• Grails默认带有Hibernate，但你也可以使用其他持久化框架。今天还有5个可用的持久化插件。
• 日志显然不是Graeme Rochers考虑的问题，但它已经稳步改进。我没有遇到过未记录错误的问题（你必须确保在你的代码中正确捕获异常）
• 调试显然不在计划之内（但这并没有改善）。我们不依赖于调试。

话虽如此，像所有新技术一样，我建议制作原型、进行代码审查、双人编程，甚至可能使用一些咨询。

- Olivier Gourment

Answer 5

很值得。我已经使用它一年多了，非常喜欢它。我曾经避开这些类型的 rad 工具，但它改变了我的工作方式。随着 1.2 版本的发布，它变得更好了，提供了更好的堆栈跟踪信息（特别是针对 GSPs）。

我遇到的唯一问题就是扩展时的 hibernate 和它的缓存，这实际上并不是一个 grails 问题。即使我不喜欢 hibernate，但 grails 用 GORM 包装它的方式对我来说是一种艺术形式。criteria 闭包方面的工作非常棒。

- Robert

Answer 6

我还没有找到既精通Grails又擅长Rails而且更喜欢Grails的人。

如果你两者都很熟悉，那么你几乎肯定更喜欢Rails。

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

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

- optimisticmonkey

---

一针见血。很遗憾但又如此真实：技术人员（也称程序员）害怕变革，即使这意味着改变会变得更好... - levifig

Answer 7

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

它真的会带来快速开发的好处吗？

当然，它确实会。即使我们提前离开脚手架路径，并且按照自己的需求覆盖约定，启动期也非常短，因为我们不必关心许多不同的技术。这种轻量级使我们不仅工作更快，而且更加精确和干净。

编写标签从未如此简单 - 虽然在JSF中我们首先要考虑是否值得付出努力，但是在Grails中，我们只需要做到这一点。进行测试驱动并实现高覆盖率也变得非常容易，尽管不同的测试用例和模拟策略有时不一致且存在错误。

从Java转换到Groovy是一件很愉快的事情，我们喜欢列表和映射文字、闭包、构建器，抛弃我们在Java中的样板“map”实现，编写简洁、有意义和专注的代码。

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

- hlg

Answer 8

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

它是否克服了起步时的错误？

• 是的，它已经克服了这些问题。我在Grails 2.0.4/2.2.4上遇到过一些Grails错误。

它真的能够提供快速开发的好处吗？

• 学习起来相当简单，易于开发，我从未见过任何一个对Java世界有很好了解的人需要超过一个工作周来掌握基础知识。而且易于维护。你不必过多地担心你的数据库 - 只需确保你正在做正确的事情。

Eclipse插件是否比以前更好并且能够胜任其职？

• 非常小心地选择你的IDE。Eclipse帮助了我很多，但它会崩溃并引起更多麻烦。我选择了IntelliJ，在试用期一个月内似乎是更好的选择。最近我一直在使用Sublime Text，一些插件和旧命令行。我只在特殊情况下使用IDE - 比如使用其调试器。

它对于真实世界的生产应用程序表现如何？

• 它有点重。在编写模型之前，请仔细研究您的设计选择。进行大量关于良好的Grails设计的研究。我两年前做的大多数事情，现在我可以意识到如何更好地完成，因为我更有经验了。它可以很好地处理真实世界的生产应用程序，但是根据你所犯的错误，Hibernate可能会让你头疼。

- Bianca Rosa

---

学习Java相当简单，易于开发。我从未见过任何了解Java世界的人需要超过一周的时间来掌握基础知识。但是在生产环境中，你可能会花费数月的时间来解决Grails问题。这些问题大多是由于误用几乎所有试图封装在引擎盖下的工具所导致的。选择IDE时要非常小心。Eclipse很糟糕，有人会明确地说吗？ :)它有点重，但简单的答案是否定的。 - Andrej Istomin

Answer 9

调试真的很难。 我从未觉得这是一个大问题。您可以附加调试器并逐步执行，或者在代码中添加大量println/logs以了解正在发生的情况。

记录日志真的很糟糕。 我同意堆栈跟踪通常提供4页无用信息，偶尔有一行信息。但是这是为了使用如此棒的框架而付出的微不足道的代价。

STS Eclipse IDE的价值有限。 Eclipse对Grails支持非常差。如果可能的话，请使用IntelliJ。虽然我很吝啬，但如果公司允许我，我会很乐意支付购买IntelliJ的费用。

- Amoeba

---

实际上，使用IntelliJ Idea进行调试非常简单，除了一些小的不便之外，比如需要展开观察变量。 - Victor Sergienko

Answer 10

我从Grails 1.0-beta版本初期就开始使用了，如果你来自Java团队，我强烈建议你开始认真考虑Groovy/Grails。

如果你正在考虑Ruby on Rails，但是你的团队是Java团队，请停止考虑并选择Grails。如果Grails对你不起作用，那么你可以随时开始学习Rails。

- Teo Choong Ping