Grails（现在）值得吗？

Question

我知道这是一个duplicate，然而，Grails世界在一年多前提出这个问题已经有了很大的进展，就像Eclipse中的IDE支持一样，所以请不要盲目关闭它。

我认为答案是肯定的，并且已经开始使用Grails 1.2.0进行了一个新项目，并且调查了STS Eclipse Integration的Groovy / Grails位。

我认为这个问题值得重新审视一年后的Grails进化，当答案肯定是混合的。

因此，作为一名经验丰富的Java Web开发人员，我有这些问题，并希望我的假设受到挑战：

• Grails现在值得与Ruby相比还是自己动手？
• 它是否已经克服了它的错误开始？
• 它真的能带来快速发展的好处吗？ （我承认我现在很挣扎，我已经通过广泛的基线配置来制作我的定制应用程序，而不是列表和页面导向）
• 它是否适用于真实世界的制作应用？ （感觉很重）
• Eclipse插件是否比它更好并且适合用途？ （我认为还没有）

由于

修改 我正在学习，我对框架的生活有一些重要的抱怨 - 而不是框架功能本身。我添加这些是因为我认为它们应该是考虑因素并且基于我的经验和意见，并且可以帮助那些试图决定是否去学生的人。我也可能表现出我对框架缺乏经验，因此这些都不是批评的批评。我是一位经验丰富的开发人员，这就是我所发现的：

调试真的很难。事实上，它几乎是不可能的，特别是作为框架中的初学者，当你最需要可靠的调试器朋友时。我花了更多的时间来跟踪代码的某些部分中的语法错误问题，以及引用在堆栈中某处导致静默失败的域字段。

记录非常糟糕。你有两种模式，“没什么用处”和“过多无用的东西”。单个页面请求后，我的调试日志为128Mb，并且不包含任何有关我的错误的信息。在我看来，整个日志问题需要在框架中重新考虑。

STS Eclipse IDE具有边际价值。除了语法高亮之外，它没什么用处。您无法调试代码，因此它是一个美化的编辑器。代码提示是不完整的，据我所知，根本没有GSP支持。它也是我桌面上最慢的Eclipse插件 - 大约2分钟即可启动。这是非常缓慢的。我已经恢复了文本编辑器（您会注意到所有在线教程视频也会这样做）和一些自定义语法hilighting。

我对性能有一些严重的担忧。有点太早说，但我已经发现自己因为休眠而调整了数据库。也许这是可以预料到的，但我真的必须保持我的域模型简单的约定，以产生高性能的查询。

最后一个，您的逻辑域模型和您的物理数据库模型应该相同的约定不是一个明智的默认设置，在现实世界中不太可能出现这种情况。我知道你可以将两者分开，但它会产生一定程度的复杂性，如果扩展惯例，我认为可以避免这种复杂性。关于构图和what you need to do to make it work in practice的文档不充分。

Answer 1

我已经使用Grails超过4个月了，我将尝试给你我个人对Grails及其可用性的感觉。

  

Grails现在是否值得与Ruby或其他人自己合作？

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

  

它是否已经克服了它的错误开始？

是即可。如果你看一下我最初的消息（在这个网站或其他网站上），我对Grails的bug很抱怨。但是，你只需要记住Grails在边缘有点粗糙（例如，不要过多地使用域继承），一旦你熟悉了框架，你就不会遇到太多不好的意外。我并不是说Grails不是马车。它肯定不仅仅是Rails。但是，它比 更有用。一条忠告：使用尽可能少的插件。因为它们中的许多都是马车，而且有些不兼容。所以，不要包含grails插件，除非你确定grails插件是最新的，非侵入式的并经过测试（由你自己）。

  

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

是即可。您几乎不需要处理数据库设计。由于Convention over Configuration，配置几乎从一开始就为您完成。您的应用程序很容易维护。我看到的唯一缺点是前端开发没有其他技术（如Rails或ASP）那么丰富

  

它是否适用于真实世界的制作应用程序？

我不能说因为我仍然没有访问我的网站，但我非常自信，因为 sky.com 正在使用Grails并且网站吸引了大量的流量 - 周围 每天700万次页面浏览量。性能再次取决于您的应用程序架构和设计决策。

  

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

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

我希望它有所帮助。

Answer 2

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

Rails 的主要内容是有很多东西对dev（我讨厌）完全不透明，当你开始添加更多插件时，这会增加/ generators / libs / etc，因为要合并它们，你需要修补一些东西。您会感觉 rails + plugins 只是一个巨大的DSL破解，如果您使用插件+版本的错误组合，它就会开始破坏。

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

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

• 语言实现：我更喜欢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或Cloud服务等新东西的库，而Java有大量的库用于Excel处理等旧版本。不要忘记Java库通常比Ruby
快得多
• 前沿：Rails更加炒作，这意味着拥有更多资源。这意味着如果你试图将MongoDB或Riak与Rails集成，那么有人已经做出了很好的改变。 Grails是滞后的，主要是因为它不那么流行，所以社区倾向于专注于解决日常问题，而不是使用像NoSQL等所有流行的东西。

以下是一个例子：

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

---

结论：

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

Answer 3

非常值得！

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

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

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

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

现在，关于可行性：

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

• 工具：Netbeans在这方面确实有所改进，但它甚至还没有像Intellij IDEA这样的其他工具（非常支持！）。关于Eclipse也是如此。

• 便携性：我们的项目从未遇到任何问题。

Answer 4

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

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

这就像所有新技术一样，我建议制作原型，代码评论，配对编程，也可以使用一些咨询。

Answer 5

非常值得。我已经使用它超过一年了，并且喜欢它。我过去常常回避这些类型的rad工具，但它改变了我的工作方式。随着1.2版本的发布，它可以获得更好的堆栈跟踪信息（特别是对于GSP）。

我在缩放方面遇到的唯一问题是hibernate和它的缓存，这实际上不是grails问题。即使是那些我一般不喜欢休眠的人，Grails用GORM包装它的方式对我来说也是一件艺术品。标准关闭方面非常适合使用。

Answer 6

我还没有找到一个熟悉Grails和Rails并且更喜欢Grails的人。

如果你们两个都很清楚，那么你几乎肯定更喜欢Rails。

Grails通常会吸引那些担心平台变化的Java开发人员。

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

Answer 7

最近我使用Grails作为项目，我希望与标准J2EE应用程序开发相比，分享我们的经验。

  

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

当然，确实如此。即使脚手架路径提前离开并且约定覆盖了自己的需求，启动期也很短，因为我们不必关心许多不同的技术。这种轻量化使我们不仅工作更快，而且更加精确和清洁。

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

从Java切换到Groovy是一件非常愉快的事情，我们喜欢拥有列表和地图文字，闭包，构建器，抛弃我们在Java中的锅炉板“map”实现，并编写紧凑，有意义且专注的代码。

降低开发速度的原因是不那么完美的IDE支持，这也适用于我们使用的IntelliJ插件。分散在不同地方的糟糕的，通常是旧的甚至是错误的文档（挫败了“搜索结束”的承诺）也阻碍了快速发展。所以我们经常不得不回到源代码阅读 - 随后被底层的Spring类层次结构吓到了。

Answer 8

调试非常困难。 我从来没有发现这是一个大问题。你可以附加一个调试器并遍历，或者将一堆println / logs粘贴到代码中以解决最新情况。

记录非常糟糕。 我同意堆栈跟踪通常提供4页无用的信息，偶尔会提供信息。然而，为这样一个令人敬畏的框架付出的代价很小。

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

Answer 9

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

如果你是一家Java商店并考虑使用Ruby Rails，那就去吧 - 去Grails吧。如果grails不适合你，那么你总是可以启动Rails。

Answer 10

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

  

它是否已经克服了它的错误开始？

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

  

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

• 学习起来非常简单，易于开发，从未见过任何对Java世界有深入了解的人需要花费超过一周的时间来了解基础知识。也易于维护。而且你不必担心你的数据库很多 - 只要确保你的重生

  

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

• 非常仔细地选择您的IDE。 Eclipse对我帮助很大，但崩溃并导致更多麻烦。我选择了IntelliJ，在试用月份，它似乎是一个更好的选择。最近我一直在使用Sublime Text，一些插件和旧的命令行。我只在特殊情况下去IDE - 例如使用它的调试器。

  

它是否适用于真实世界的制作应用程序？

• 有点沉重。在编写模型之前，要对您的设计选择进行大量研究。做了很多有关Grails设计的研究。我两年前做过的大部分事情都可以让我意识到如何让它变得更好，因为我更有经验。它可以很好地处理真实世界的制作应用程序，但是根据你犯的错误，Hibernate真的很难过。

Answer 11

我建议你自己尝试一下。我喜欢Grails的灵活性和开发速度。但是你可以看到其他人的经历不同。我希望能够使用Java平台为我的客户开发快速应用程序，我发现Grails可以很好地为我们工作。

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

Answer 12

根据我的经验，Grails在桌面上带来了一些极具吸引力的功能，绝对值得学习和使用。

• 敏捷 - 我们过去需要花费数周才能在传统J2EE项目中实现的东西通常是使用grails插件系统的一天工作。像ajax，jquery ui，acegi，restful implementation，scheduler system以及很多这样的东西
• 在JVM上运行，减少了学习其他运行时系统及其特性的需要

• Java喜欢语法和groovy语法糖。最喜欢这两个世界。您可以立即从Java开始，而不是学习像Ruby这样的新语言的语法，然后慢慢地你可以转向强大，简单和直观的groovy语法

  对于项目经理来说，除非出于某种原因“不使用”grails有令人信服的理由（来自更高层次的阻力，采用新技术或其他东西），我认为没有任何理由不能使用grails使用过或至少尝试过。

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

Answer 13

Grails Eclipse插件是垃圾。它毫无理由地崩溃，并不能真正支持Groovy的灵活性。据传NetBeans和IntelliJ要好得多，但我还没有尝试过。

它有效吗？当然可以。甚至Ruby on Rails也会执行，只要你在这个问题上投入足够的服务器。不过，我不知道Grails如何与各种Java框架进行比较。

它真的能带来快速发展的好处吗？好吧，我仍然缺少很多很好的Ruby / Rails东西。它不会自动识别日期和枚​​举请求参数（然后，Rails也有一些日期问题），TimeCategory应该是标准配置的一部分但不是。但是还有很多东西需要非常少的配置。

这并不是Rails所在的地方（我特别期待Rails 3），但与许多Java框架相比，使用起来要好得多。即便如此，表面下方的魔法也比Rails更深。例如，Constraints的系统非常强大，但是建立在一层巨大的无法穿透的Spring之上，如果你想以稍微不同的方式使用相同的功能，那么它就非常不灵活。 Rails更容易被颠覆，IME。

值得吗？是。这是一个比其他更好的选择吗？这取决于。

Answer 14

关于eclipse插件，仍然是它的方式，但你可以使用Spring Source（SpringSource Tool Suite）的eclipse版本

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

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

Answer 15

  

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

去年它确实有了很大改善。十二月，我参加了伦敦的Groovy＆amp; Grails Exchange。关于已记录的Eclipse / SpringSource STS中的Groovy＆amp; Grails集成，有一个很好的讨论，请参阅video。

从我的观点来看，Eclipse获得了很多支持。目前，IntelliJ似乎略微领先，但可能会在未来几个月内发生变化。

Answer 16

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

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

现在我正在使用STS进行编程，我发现很高兴与Grails一起使用，尽管我仍然发现方法检测/完成可以更好地工作。

Answer 17

  

它是否已经克服了它的错误开始？

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

  

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

我花了一个小时制作Grails的测试来在控制台中输出内容（它不能开箱即用），即使在Java中，你也不会花费这么多时间从测试中输出内容。

  

它是否适用于真实世界的制作应用程序？

我仍然不认识一个着名公司正在用Grails构建一些东西。

  

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

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

所以，回答主要问题：

  

Grails（现在）值得吗？

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

Answer 18

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

赞成

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

缺点

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

Answer 19

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

就就业市场而言，据我所知，Grails程序员在职位空缺公告中的需求与例如Django和Ruby on Rails。

Answer 20

我会说不。对于大多数用途来说，它仍然是臃肿的，imho，特别是如果你只是想要原型。我们不需要所有的代码，所有那些与grails捆绑在一起的依赖项，以便创建Web应用程序。每次想要发布Web应用程序时都不需要spring。在向整个堆栈添加完整的依赖项之前，请查看您要完成的任务。我认为了解您的应用程序包含的内容非常重要。

我建议看看像ratpack这样的东西，它更轻，就像红宝石的sinatra一样。

Answer 21

我是一名全职的Java开发人员，但我的业余爱好项目使用rails。我们评估了一年前工作项目的Grails。我对grails的体验让我感到有些失望，这就是我开始研究rails的原因。使用我的印象是，虽然groovy与ruby作为一种语言并不遥远，但rails提供了比grails更好的体验。很简单，rails似乎解决了更多现实世界的问题，特别是当你考虑到可用的好宝石数量时。我正在考虑提供搜索，版本控制，rss，非crud应用程序，与云服务集成等等。 我得到的印象是，grails大约是rails 1.x的水平。到本月底，轨道3应该已经发布。我们实际上决定现在在工作中使用rails。最后，Java开发人员更容易获得grails，但最终缺乏改进以满足更广泛的项目需求。