Grails (现在)值得吗？

我知道这是一个 复制品，但是，自从一年多以前人们提出这个问题以来，Grails 世界已经发生了很大的变化，Eclipse 中的 IDE 支持也是如此，所以请不要盲目地关闭它。

我认为答案是肯定的，并已经开始了一个新的项目与 Grails 1.2.0，并已经调情与 Groovy/Grails 位的 STS Eclipse 集成。

经过一年的 Grails 发展，我认为这个问题值得重新讨论，当时的答案肯定是喜忧参半的。

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

  • Grails 现在是否值得与 Ruby 进行竞争，或者是否值得推出自己的 Grails？
  • 它克服了它的错误开始吗？
  • 它真的能带来快速开发的好处吗
  • 它适用于真实世界的生产应用程序吗
  • Eclipse 插件是否比以前更好并且适合用途

谢谢

编辑: 我一边学习一边学习，对于使用框架——而不是框架本身的能力，我有一些重要的抱怨。我添加这些，因为我认为它们应该是考虑因素，并根据我的经验和意见，可能有助于人谁正在尝试决定是否去圣杯。我也可能表现出我在框架方面缺乏经验，所以这些都不是彻头彻尾的批评。我是一个经验丰富的开发人员，这是我发现:

调试真的很难。事实上，这几乎是不可能的，尤其是作为框架的初学者，这是您最需要您可信赖的调试器朋友的时候。我花费了比我应该花费的时间更多的时间来跟踪代码中的某些语法错误问题，这些错误与引用域字段有关，这些字段会导致堆栈中某处的无声故障。

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

STS Eclipse IDE 具有边际价值 。除了语法突出显示外，它没有多大用处。你不能调试代码，所以它是一个美化的编辑器。代码提示是不完整的，在我看来根本没有 GSP 支持。它也是我的桌面上运行速度最慢的 Eclipse 插件——只有2分钟的启动时间。速度慢得惊人。我已经恢复到一个文本编辑器(你会注意到所有的在线教程视频也这样做)和一些自定义语法突出显示。

我对性能有一些严重的担忧。现在下结论还为时过早，但我已经发现自己正在因为休眠而调整数据库。也许这是意料之中的，但是我真的必须保持我的域模型简单，以便约定产生性能查询。

最后一点，逻辑域模型和物理数据库模型应该相同的约定不是一个明智的默认值，在现实世界中也不太可能是这样。我知道你可以把这两者分开，但是这会造成一定程度的复杂性，我认为如果扩展这些约定，就可以避免这种复杂性。关于组合和 你需要做什么才能让它在实践中发挥作用的文档不足。

15176 次浏览
小开

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

现在 Grails 和 Ruby 或者其他你自己的卷相比值得吗？

当然，答案不是“是”或“否”，而是 看情况了。这取决于您的需求(您需要在 Java 世界中吗?)，在您的首选项上(您是否更喜欢面向领域的开发，您是否更喜欢 Groovy...) ？ 不过，我可以回答说，Grails 是 Rails 的一个重要替代品。我相信无论您的 Rails 应用程序是什么，您都可以使用 Grails 来完成它。但是，根据项目的性质，这可能需要更多或更少的时间。同样，如果您熟悉 Rails 但不熟悉 Grails，那么 Rails 是更安全的选择。

它克服了它的错误开始吗？

是的。如果你看看我最初的消息(在这个网站或其他) ，我抱怨了很多关于 Grails 的 bug。但是，您只需要记住 Grails 的边缘有一点粗糙(例如，没有过多地使用域继承) ，一旦您熟悉了框架，您就不会遇到太多糟糕的意外。我不是说 Grails 没有 bug。它当然不仅仅是 Rails。但它也是 比马车更实用。给你一个建议: 使用尽可能少的插件。因为它们中的许多是有缺陷的，而且有些在它们之间是不兼容的。因此，除非您确定 grails 插件是最新的、非侵入性的并且(由您自己)经过测试，否则不要包含 grails 插件。

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

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

它能在现实生产应用程序中运行吗？

我不能说，因为我仍然没有去我的网站现场，但我相当有信心，因为 Sky.com是使用 Grails 和网站吸引了大量的流量- 周围 每天700万页面浏览量。同样，性能在很大程度上取决于您的应用程序架构和设计决策

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

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

希望能有所帮助。

小开

我是一个全职的 java 开发人员，但使用轨道为我的业余爱好项目。一年前我们为一个项目评估了 Grails。我对圣杯的体验让我感到有点失望，这就是我开始研究轨道的原因。在使用了这两种语言之后，我的印象是，尽管 Groovy 在语言方面并不比 Ruby 差多少，但是 Rails 提供了比 grails 更好的体验。很简单，Rail 似乎可以解决更多现实世界中的问题，特别是当您考虑到可用的好的 gem 的数量时。我正在考虑一些事情，比如提供搜索、版本控制、 RSS、非垃圾应用、与云服务的集成等等。 我得到的印象是，grails 大约是轨道1. x 的水平。到本月底，Rails3应该已经发布了。我们现在已经决定在工作中使用轨道。最后，grails 对于 Java 开发人员来说更容易掌握，但是最终缺乏覆盖更广泛项目需求的细化。

小开

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

在过去的一年里，情况确实有了很大的改善。12月，我参加了伦敦的 Groovy & Grails 交易所。关于 Eclipse/SpringSource STS 中的 Groovy & Grails 集成有一个很棒的演讲，已经被记录下来了，参见 视频。

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

小开

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

有用吗？当然有关系。只要抛出足够多的服务器来解决问题，甚至 RubyonRails 也可以执行。但是，我不知道 Grails 如何与各种 Java 框架进行比较。

它真的能带来快速开发的好处吗？我还是错过了很多 Ruby/Rails 的好东西。它不能自动识别 Date 和 Enum 请求参数(然后，Rails 也有一些与 Date 有关的问题) ，TimeCategory 应该是标准配置的一部分，但不是。但是也有很多东西需要非常小的配置。

虽然不完全是 Rails 所处的位置(我特别期待 Rails 3) ，但是与许多 Java 框架相比，它的工作方式要愉快得多。即便如此，表面之下的魔力比 Rails 深刻得多。例如，Constraint 系统非常强大，但是构建在一个庞大的、难以理解的 Spring 材料层之上，如果您想以稍微不同的方式使用同样的强大功能，那么它非常不灵活。Rails 更容易被破坏，IME。

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

小开

这是非常值得的！

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

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

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

  • 遗留数据库结构——如果您想在遗留数据库上生成数据可视化，这是一个非常棒的工具。

现在，关于生存能力:

  • Bug: 自从版本1.1以来，我们还没有遇到过太多的 bug (版本1.0对我们来说 bug 太多了)

  • Tools: Netbeans is really improving on this front, but it's not even close other tools like Intellij IDEA (great support!). The same can be said about Eclipse.

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

小开

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

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

小开

关于 eclipseplugin，还在进行中，但是你可以使用 SpringSource (SpringSource 工具套件)的 eclipseversion

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

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

小开

非常值得。我已经用了一年多了，很喜欢。我过去常常回避这些类型的酷工具，但它已经改变了我的工作方式。随着1.2版本的发布，它已经得到了更好的堆栈跟踪信息(特别是对于 GSP)。

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

小开

目前，我们已经有六个 Grails 应用程序投入生产，尽管 Grails 与 Java 框架不同，需要一些学习时间，但它已经取得了成效，因为我们已经使用了敏捷技术。详情:

  • 我们使用 IntelliJ。它不是非常昂贵，并已在几个星期内为我们偿还。
  • 对于所有动态语言代码来说，自动化测试、持续集成和重构是必须的。如果您已经实践了 TDD 或者至少有一个不错的测试代码覆盖率，那么它不会增加任何额外的工作。
  • Hibernate 默认带有 Grails，但是您可以使用其他持久性框架。目前还有5个其他可用的持久性插件
  • 显然，格雷姆 · 罗彻斯并不担心伐木问题，但伐木问题已经得到了稳步改善。但是，我还没有遇到过没有记录错误的问题(您必须确保在代码中正确捕获异常)
  • 调试显然不在我们的考虑范围之内(但是这并没有改进) ，我们并不依赖于调试。

这就是说，对于所有的新技术，我建议制作原型、代码评审、结对编程，也可以使用一些咨询。

小开

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

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

当然了。即使脚手架路径提前离开并且约定被覆盖到自己的需求，启动周期也非常短，因为我们不需要关心许多不同的技术。那种轻便不仅使我们工作更快，而且更精确和干净。

编写标记从来都不是一件容易的事情——而对于 JSF，我们首先考虑的是它是否值得付出努力，而对于 Grails，我们只是这样做。尽管不同的测试用例和模仿策略有时是不一致的和错误的，但是测试驱动和实现高覆盖率还是很容易的。

从 Java 切换到 Groovy 是一种极大的乐趣，我们喜欢列表和映射文本、闭包、构造器，抛弃我们的 Java“ map”实现，编写紧凑、有意义和重点突出的代码。

降低开发速度的是不那么完美的 IDE 支持，我们使用的 IntelliJ 插件也是如此。糟糕的、经常是旧的甚至是错误的文档分散在不同的地方(破坏了“搜索结束”的承诺) ，这也阻碍了快速开发。因此，我们常常不得不退回到源代码阅读——随后被底层 Spring 类层次结构吓到了。

小开

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

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

  • 类 Java 语法和 Groovy 语法 Sugar。两全其美。你可以立即从 Java 开始，而不是像 Ruby 那样学习新语言的语法，然后慢慢地，你可以转向 Groovy 语法，它是健壮的，简单的，直观的

    对于项目经理来说，除非出于某种原因(来自高层的阻力，采用新技术或其他原因)有令人信服的理由“不使用”grails，否则我看不出有任何理由不使用或至少尝试一下 grails。

要回答关于调试的问题，这并不难。如果使用 Netbeans IDE，则调试很容易。这又让我想到一点。在对所有 IDE 进行了一些实验之后，我们发现 Netbeans 是最适合做这项工作的。它对代码完成、语法突显和调试等有更好的支持。在我看来，化粪池系统不足以做到这一点。

小开

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

我使用 铁路的主要原因是，有很多东西对于开发人员来说是完全不透明的(我讨厌这种情况) ，当你开始添加更多的 插件/生成器/库/etc 时，这种情况会增加，因为为了组合它们，你需要修补一些东西。你会感觉到 Rails + 插件只是一个巨大的 DSL 黑客，如果你使用一些错误的 插件 + 版本组合，它就会开始崩溃。

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

做一个1比1的比较，是这样的:

  • 语言实现 : 相对于 Groovy，我更喜欢 Ruby，尽管我不太了解 Ruby。Groovy 感觉像是一种好意坏意的实现语言，其中一些特性被焊接在语法之上。我指的是一些特殊的类，似乎只允许一些黑客。
  • 框架特性 : Rails 在这方面遥遥领先。您可以通过几种方式配置 Rails 的大多数方面(例如: 布局、模板、 css/js 封装器、验证、测试框架等)。尽管 Grails 对于大多数用例来说足够灵活，但它在这方面还是落后了。
  • 插件 : Rails 拥有大量的插件，这些插件可以被视为福音，也可以被视为噩梦。有些插件没有得到维护，有些插件不能很好地与某些特性或插件相结合，还有很多分叉。我正在学习坚持使用基本的和最常用的插件(authlogic、 haml 等) Grails 有很好的基础插件(授权/认证、 ORM 等)和一些其他的小插件
  • 测试 : Rails 有大量的测试方法，但是这不一定是好的。一些测试框架不能很好地与一些插件一起工作，等等。Grails 拥有较少的测试插件，但是他们倾向于更好地与一些主要插件集成(因为没有那么多插件需要集成)
  • Database : Grails win 到目前为止数据库 : Grails 赢得 到目前为止。
    • 我更喜欢建模我的领域类，而不是黑客我的数据库。
    • Hibernate (它是在引擎盖下使用的)离 Rails 版本还有好几年的时间。虽然 Rails 有一个 datamapper (它在本质上与 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 风格的数据库，使用 铁路。此外，Ruby 作为一种语言是非常优雅的
  • 如果你喜欢类界面设计而不是 DSL，喜欢通过模型来建模你的应用程序，不需要精致的特性，并且熟悉 Java 生态系统，那么使用 圣杯
小开

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

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

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

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

小开

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

一般来说，我没有发现 RoR 和 Grails 在使用 IDE 的质量上有太大的不同。不过，公平地说，我正在 Linux 上编程，还没有尝试用 TextMate 进行 RoR 开发。当我使用 RoR 时，我使用 Netbeans。

现在我正在使用 STS 编程，我发现用 Grails 编程很有乐趣，尽管我仍然发现方法检测/完成可以做得更好。

小开

调试真的很难。 我从来没觉得这是个大问题。您可以附加一个调试器并遍历，也可以在代码中加载 println/log 来查找正在发生的事情。

伐木实在是太糟糕了。 我同意堆栈跟踪通常提供4页无用的信息，偶尔一行是信息。然而，为这样一个令人敬畏的框架付出的代价很小。

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

小开

我从1.0测试版的早期就开始使用 Grails 了，如果你来自 Java 工作室，我只能建议你开始认真对待 Groovy/Grails。

如果你是一个 Java 工作室并且正在考虑使用 RubyRails，那么停下来——去做 Grails 吧。如果 grails 不适合您，那么您可以随时启动 Rails。

小开

我会说没有。对于大多数用途来说，它仍然过于臃肿，尤其是如果您只是想要对某些东西进行原型设计的话。我们不需要所有这些代码，所有这些与 grails 捆绑在一起的依赖关系，就可以创建一个 Web 应用程序。你不需要在每一次发布 web 应用程序的时候都使用 spring。在向堆栈中添加一个充满依赖项的世界之前，请考虑一下您要完成的任务。我认为了解您的应用程序包含哪些内容非常重要。

我建议你看看“老鼠背包”这种比较轻的，就像红宝石的辛纳屈。

小开

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

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

小开

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

优点

  • 当您使用很少的插件并限制一组 Grails no-s 和 never-s 时，这是一个相当平稳的开发体验

缺点

  • 刷新(F5)总是一个问题。这是最烦人的。由于某种原因，我不得不在每次3-4次刷新时重新启动服务器。有一个众所周知的重新启动错误: 问题1，问题2，虽然它很少发生。
  • 语言级别的错误。当我使用静态内部类时，我总是需要在更改时重新启动服务器。虽然构建没有问题，但语言的使用对我来说是有限的
  • 启动时间，构建时间，应用程序大小(一个小应用程序70兆) ，内存使用
  • 只有远程调试，IDE 调试是非常不稳定的
小开

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

它克服了它的错误开始吗？

  • 是的，我在 Grails 2.0.4/2.2.4上遇到过一些 Grails bug。

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

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

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

  • 仔细选择您的 IDE。Eclipse 帮了我很大的忙，但是它崩溃了，造成了比它应该造成的更多的麻烦。我选择了 IntelliJ，在试用期，这似乎是一个更好的选择。最近我一直在使用 SublimText、一些插件和旧的命令行。我只在特殊情况下使用 IDE ——例如，使用它的调试器。

它能在现实生产应用程序中运行吗？

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

它克服了它的错误开始吗？

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

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

我花了一个小时来做 Grails 的测试，以便在控制台中输出一些东西(它不能开箱即用) ，即使在 Java 中，您也不会花这么多时间来从测试中输出一些东西。

它能在现实生产应用程序中运行吗？

我仍然不知道有哪个著名的公司正在用 Grails 开发什么东西。

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

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

那么，回答主要问题:

Grails (现在)值得吗？

如果您无力支付 MicrosoftAccess 许可证的费用，也许可以这样做。对于真正的项目，我会远离圣杯。事实上，这只是一个流产的孩子。


提交答案