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

我知道这是重复的，但是，自从一年多前提出这个问题以来，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分钟才能启动。令人震惊的缓慢。我已经恢复到文本编辑器（您会注意到所有在线教程视频也都这样做）和一些自定义语法提示。

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

最后一点，关于逻辑域模型和物理数据库模型应该相同的约定不是明智的默认选择，在现实世界中不可能如此。我知道您可以将两者分开，但这会造成一定程度的复杂性，我认为如果扩展约定，可以避免。没有足够的文档来说明合成以及在实际操作中需要做什么。

我已经使用Grails超过4个月了，我将尽力让您对Grails及其可用性感到满意。

Grails与Ruby或其他工具相比现在值得吗？

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

它克服了越野车的起步吗？

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

它真的赋予快速发展利益吗？

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

它可用于现实世界的生产应用程序吗？

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

Eclipse插件是否比以前更好并且适合特定目的？

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

希望对您有所帮助。

最近启动了一个Rails项目，一直在与Grails合作。

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

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

进行一对一比较，方法如下：

• 语言实现：尽管我不太了解Ruby，但我更喜欢Ruby而不是Groovy。Groovy感觉像是一种好意不好的实现语言，其中某些功能融合在语法之上。我指的是一些特殊的类，似乎只允许进行一些破解。
• 框架功能：Rails在这一方面遥遥领先。您可以通过多种方式配置Rails的大多数方面（例如：布局，模板，css / js包装器，验证，测试框架等）。尽管对于大多数用例而言，Grails足够灵活，但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风格的DB，请使用Rails。此外，Ruby作为一种语言非常优雅
• 如果您更喜欢类接口设计而不是DSL，更喜欢通过模型为应用程序建模，不需要精致的功能并且熟悉Java生态系统，请选择Grails

非常值得！

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

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

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

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

现在，关于可行性：

• 错误：自1.1版以来，我们并没有遇到太多错误（1.0版对我们而言过于错误）

• 工具：Netbeans在这方面确实在改进，但是它甚至还没有关闭其他工具，例如Intellij IDEA（强大的支持！）。关于Eclipse也可以这样说。

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

现在，我们有六个Grails应用程序在生产中，尽管Grails与Java框架不同并且需要一定的学习时间，但由于我们使用了敏捷技术，因此它得到了回报。细节：

• 我们使用IntelliJ。它不是很昂贵，已经在几周内为我们偿还了。
• 对于所有动态语言代码，必须进行自动化测试，持续集成和重构。如果您已经练习过TDD或至少具有不错的测试代码覆盖率，则它不会增加任何额外的工作。
• 默认情况下，Hailnate是Grails附带的，但是您可以使用其他持久性框架。今天有5个持久性插件其他可用
• 伐木显然不是Graeme Rochers所关心的，但它一直在稳步改善。不过，我还没有遇到未记录错误的问题（您必须确保在代码中正确捕获了异常）
• 调试显然不在雷达范围内（但是并没有得到改善）。无论如何我们都不依赖调试。

这就是说，与所有新技术一样，我建议您进行原型设计，代码审查，结对编程，并可能还需要进行一些咨询。

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

我在扩展方面遇到的唯一问题是休眠状态，它是缓存，这确实不是一个难题。即使是那些我通常不喜欢冬眠的人，Grails用GORM包装它的方式对我来说也是一件艺术品。准则封闭方面非常好用。

我还没有找到在Grails和Rails方面都精通并且更喜欢Grails的人。

如果你们两个都知道，那么您几乎可以肯定会喜欢Rails。

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

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

最近将Grails用于一个项目后，我想与标准J2EE应用程序开发相比，分享我们的经验。

它真的赋予快速发展利益吗？

当然可以。即使脚手架走得很早并且惯例被自己的要求所取代，启动期也很短，因为我们不必关心许多不同的技术。这种轻量级的功能使我们不仅可以更快地工作，而且可以更加精确和整洁。

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

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

减慢开发速度的是不够完美的IDE支持，我们使用的IntelliJ插件也是如此。散布在不同地方的坏的，经常是旧的甚至是错误的文档（违反了“搜索结束”的诺言）也阻碍了快速发展。因此，我们常常不得不回过头来阅读源代码-随后被底层的Spring类层次结构吓到了。

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

它克服了越野车的起步吗？

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

它真的赋予快速发展利益吗？

• 学习起来非常简单，易于开发，从来没有见过任何对Java领域有充分了解的人花了一个多星期的时间来了解基础知识。也易于维护。而且您不必担心数据库的烦恼-只需确保您是麦可

Eclipse插件是否比以前更好并且适合特定目的？

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

它可用于现实世界的生产应用程序吗？

• 很重。在编写模型之前，请对您的设计选择进行大量研究。对良好的Grails设计进行大量研究。两年前我做过的大多数事情，由于我比较有经验，所以我现在可以意识到如何做得更好。它可以很好地处理现实世界中的生产应用程序，但根据您犯的错误，Hibernate确实令人头疼。

调试真的很难。 我从来没有发现这是一个大问题。您可以连接调试器并逐步执行，也可以将大量的println / logs粘贴到代码中以了解发生的情况。

坦率地说，日志记录很糟糕。 我同意堆栈跟踪通常会提供4页无用的信息，偶尔还会提供有用的信息。但是，为如此出色的框架付出的代价很小。

STS Eclipse IDE具有边际价值。 Eclipse对Grails的支持很少。如果可能，请使用IntelliJ。我是个顽固的家伙，但是如果我的公司允许我，我很乐意为IntelliJ支付现金。

从1.0测试版开始，我就一直在使用Grails，并且如果您来自Java商店，我只能建议您开始认真考虑Groovy / Grails。

如果您是Java商店并且考虑使用Ruby Rails，请停止-前往Grails。如果grails不适合您，则可以随时启动Rails。

Grails Eclipse插件很糟糕。它完全没有理由崩溃，并且不真正支持Groovy的灵活性。有传言说NetBeans和IntelliJ会更好，但是我还没有尝试过。

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

它真的赋予快速发展利益吗？好吧，我仍然缺少很多好的Ruby / Rails东西。它不能自动识别Date和Enum请求参数（然后，Rails的Date也有一些问题），TimeCategory应该是标准配置的一部分，但不是。但是也有很多东西需要很少的配置。

这并不是Rails所在的地方（我特别期待Rails 3），但是与许多Java框架相比，使用它要令人愉快得多。即便如此，表面之下的魔力还是比Rails更深。例如，Constraints系统功能强大，但建立在不可渗透的Spring东西的巨大层之上，如果您想以稍微不同的方式使用相同的功能，则它实际上是不灵活的。IME，Rails更容易被颠覆。

这值得么？是。这是比其他更好的选择吗？那要看。

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

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

以我的经验，Grails会带来一些非常吸引人的功能，这绝对值得学习和使用。

• 敏捷性-我们过去在常规J2EE项目中花费数周的时间来完成的工作通常是使用grails插件系统完成一天的工作。诸如ajax，jquery ui，acegi，restful实现，调度程序系统之类的东西
• 在JVM上运行，从而减轻了学习其他一些运行时系统及其特质的需求

• Java喜欢语法和常规语法糖。就像两全其美。您可以立即从Java开始，而不是学习诸如Ruby之类的新语言的语法，然后慢慢地，您可以转向健壮，简单且直观的groovy语法。

  对于项目经理而言，除非出于某些原因（高层的抵制，采用新技术等）有令人信服的理由“不使用” grails，否则我看不出为什么不能使用grails或存在任何理由最少尝试。

要回答有关调试的问题，这并不难。如果使用Netbeans IDE，调试将很容易。这使我不得不提一点。经过对所有IDE的几次实验，我们发现Netbeans最适合完成这项工作。它对代码完成，语法突出显示和调试等具有更好的支持。在我看来，STS尚不足以实现这一点。

Eclipse插件是否比以前更好并且适合特定目的？

在过去的一年中，它的确有了很大的改进。12月，我参加了伦敦的Groovy＆Grails交易所。已经录制了关于Eclipse / SpringSource STS中Groovy＆Grails集成的精彩演讲，请观看视频。

从我的角度来看，Eclipse获得了很多基础。目前，IntelliJ似乎还领先一点，但在未来几个月内可能会发生变化。

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

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

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

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

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

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

我是一名全职的Java开发人员，但在我的业余项目中使用了rails。一年前，我们对一个项目的grails进行了评估。我的grails经历使我感到有些失望，这就是我开始研究rails的原因。使用我的两个印象是，尽管Groovy在语言上并不落后于ruby，但Rails提供了比Grails更好的体验。简而言之，rails似乎可以解决更多现实世界中的问题，尤其是当您考虑可用的优质宝石的数量时。我正在考虑诸如提供搜索，版本控制，RSS，非原始应用程序，与云服务集成等之类的东西。到本月底，应该已经释放了滑轨3。我们' ve实际上决定现在要在工作中使用滑轨。最后，grails对于Java开发人员来说更容易掌握，但是最终缺乏完善的方法来满足更广泛的项目需求。

我会说不。对于大多数用途而言，它仍然是肿的，恕我直言，特别是如果您只想原型制作某些东西。我们不需要所有这些代码，而是将所有依赖项与grails捆绑在一起以创建Web应用程序。您不必每次都想发布Web应用程序时就需要Spring。在向堆栈添加充满依赖性的整个世界之前，请先查看您要完成的工作。我认为了解您的应用程序包含的内容很重要。

我建议您看一下类似Ratpack的东西，它要轻得多，几乎就像用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兆），内存使用情况
• 仅远程调试，IDE调试非常不稳定

它克服了越野车的起步吗？

还是很恐怖。我不知道他们的开始，但是从Grails 2迁移到Grails 3仍然是一场噩梦，而且他们所付出的努力超出了解决的范围。

它真的赋予快速发展利益吗？

我花了一个小时进行Grails的测试，以便在控制台中输出某些内容（无法立即使用），即使在Java中，您也不会花费这么多的时间从测试中输出某些内容。

它可用于现实世界的生产应用程序吗？

我仍然不知道有哪个知名公司与Grails合作。

Eclipse插件是否比以前更好并且适合特定目的？

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

因此，回答主要问题：

Grails（现在）值得吗？

如果您负担不起Microsoft Access许可证，也许可以。对于真实的项目，我会远离Grails。实际上，这只是一个死胎。