Grails值得吗？[关闭]

这是一半，一半的问题。

值得使用Grails吗？我正在尝试开发一个相对简单的数据库驱动的Web应用程序。我的专长是Java，因此Grails自然是一个不错的选择。起初，我考虑过使用Spring，JPA和Hibernate，但是我以前已经使用过它，并且遇到了各种各样繁琐的配置和编码工作。Grails在解决这一问题时做广告。

我对Grails的最大挫败是所有无法使用的小东西。我的意思是，它不像人们直觉上认为的那样起作用。边缘很粗糙。我经常遇到问题。有时是因为我对Grails缺乏了解-有时我发现了合法的Grails错误。

一个主要问题是缺乏良好的Eclipse集成。有一个Groovy和Grails插件，但是除了语法突出显示之外，它没有做其他的事情。从Java调用Groovy进行配置非常困难，反之亦然。没有良好的IDE支持是一个大麻烦。

发生的事情是我坐下来尝试开发Web应用程序。最终，我意识到我花了大约85％的时间来调试与Grails相关的问题。如果不是Eclipse问题，那就急于加载，获取视图，一对多关系，怪异的空文件bug行为，怪异的属性/获取方法bug-不断地发生着。这只是我今天遇到的问题的一个示例。我与Grails的最后一次坐坐产生了许多不同的问题。

有时我想知道这是否值得。我很好奇其他人是否经历过这种情况。实际有人在使用Grails高效地创建Web应用程序吗？我应该考虑其他用于快速Web开发的框架吗？

我们有一个由12人组成的团队，他们都是经验丰富的高级Java开发人员，他们从0.6B中学习了Grails，并且我们仍在致力于基于Grails的项目。我不会愿意回到Java，而让我们都为Grails应用程序的快速入门而感到欣慰。

这是一场斗争，这并不容易，并且有挫败感。

尽管如此，鉴于我们的不断努力，我们很快就交付了一些东西。有很多错误，很多都有解决方法。

我听说过一些擅长Java的开发人员实例，他们试图深入研究Grails项目的复杂性。我们避开了所有Java，转而使用纯Grails和Groovy。我们确保我们从简单开始，尽可能地以可管理的方式增加复杂性。.我们不敢潜入最深的一面，并希望我们的Java知识足以支撑我们。

我们最终创建了一个庞大而又复杂的东西，其工作异常出色，并且比编写纯Java / Spring / Hibernate版本要快得多。那就是没有像样的IDE支持，而且就错误而言，情况要比今天严重得多。

关于Eclipse支持，唯一用于Grails / Groovy的真正IDE是Intellij-可悲的是，Eclipse支持落后了：可悲的是：我是Eclipse爱好者，而远非Intellij转换-Grails / Groovy的支持使其他所有东西都消失了虽然。

是的，Grails与Spring相比可能还不成熟。或休眠。我敢打赌，在他们存在的头1.5年里，他们同样充满了问题。

照原样，您要承担责任，要确保将复杂性降至最低，要谨慎地进行测试（在我们看来），并逐步谨慎地建立起来。

一旦将Spring / Hibernate包含在堆栈中，Java就不会提供快速的代码解决方案。Grails体现的复杂性反映了Spring / Hibernate自身的复杂性。如果您觉得最好的时间是用纯Java来做，那么我不会反对。.我仍然有我的WTF，但是现在陡峭的学习曲线已经过去，我想我会继续尝试Grails。

我非常喜欢编写grails应用程序，原因有二：

• 我不必使用Java
• 我可以使用Java

我认为，在熟悉grails之后，人们可以非常迅速而优雅地完成工作。

好的方面太多了。缺点是性能，这在两个方面都给我带来了冲击：部署和测试驱动的开发。

我没有设法在一个（租用）服务器上运行超过3个grails应用程序，因为我很快就达到了内存和性能的极限。包含太多框架。

另外，grails的testrunner不值得这个名字。当我运行单元测试时，应该立即完成测试，而不是10到20s。所以我发现自己一直在用纯Java编写业务逻辑，因为我可以更快地对其进行测试。但是我想可以通过更好地集成到IDE（eclipse）中来解决此问题。

我认为Spring对Grails的支持将大大提高。如果有人可以将它移到网上的CRUD之上，那就是那些家伙。

我也认为它已达到临界点。有几本新书将在2009年投放市场。我认为这将有助于采用率。

我完全同意原始海报的观点。

我们是Java + Spring商店，并借此机会尝试了Grails。我们首先创建了一个非常小的测试应用程序，结果证明它非常简单，并且运行良好。我们在这里遇到的主要问题是由于我们对Groovy和Grails缺乏了解。

取得成功（增强信心）后，我们决定尝试一个更大的项目。这是一个更加痛苦的经历。正如其他人所提到的，我们发现了表面上并不立即发现的各种错误和问题。应用程序的重启周期将非常痛苦，除非您具有良好的测试覆盖面，否则进行任何形式的重构都是噩梦。

令人沮丧的是，代码失败而没有一条错误消息！它只是行不通，您不知道为什么？

我喜欢JMS，Quartz和Remoting插件的易用性。消除了许多繁琐的XML。

我几乎喜欢GORM的简单性，尽管我们也遇到了一些问题。

我不喜欢Groovy的松散类型性质，以及您必须运行您的应用程序才能捕获大量错误的事实，这让我想起了太多的PHP或Rails。

最终，我们要问自己是否可以使用Grails编写复杂的可管理软件...

我们有一个即将投入生产的Grails应用程序。...因此我们将看到。

我们在Web层上使用grails +在服务层上使用带有hibernate和spring的Java。这是经典的三层（Web，逻辑，数据），其中Web遍地都是，逻辑是用Java实现的。与Java中一样，我们使用bean对象表示不同层之间的数据。

它运行良好，并且对于我们的案例而言，这是最好的解决方案，因为bean对象已经存在，数据库结构也是如此。根据我们的经验，我认为grails作为Web表示层具有很大的价值，但是我会坚持用Java编写业务规则并保留应用程序数据-因为grails是Java，所有grails-java集成都很漂亮直截了当。

正如人们在这里所说的，我们使用eclipse开发grails应用程序，并且它的集成性很差。但是，作为其他开发人员的建议，我们从命令行运行grails应用程序，并且仅使用eclipse保存源文件，并且该应用程序可以动态更新，因此效果很好。

除了在表示层之外，在其他地方使用grails还是很不舒服的。

我对Ruby on Rails的经验比对Java世界的任何经验都多，因此我从不同的角度入手。总的来说，Grails是粗糙得多，环游边缘比Rails是，部分原因是它的不成熟，部分是因为它在最盖（Spring和Hibernate）依赖于两个出奇复杂的框架。Rails的社区也更大。

但是，Groovy作为一种语言已取得了长足的进步，并且很高兴与之合作。由于Groovy 1.6的改进，Grails比JRuby on Rails更加灵活，并且通过GPath获得了惊人的良好XML支持。通过使用JVM，您可以获得很多不错的功能（例如并发性和大量线程安全代码），而不必搞砸Java（我不太在意的语言），所以我拥有很难说服自己在MRI上使用任何东西。

我必须承认，Python看起来很诱人。

至于您的Eclipse问题，我无能为力。我使用Vim和Emacs，主要是因为我无法忍受使用IDE。但是对于动态语言，例如Groovy，Ruby和Python，我认为IDE并不会带来真正的好处，因为实际上并没有任何地方可以生成代码或进行编译。也许尝试在没有IDE的情况下工作一段时间，看看情况是否更流畅？

所以，是的，我认为Grails值得。他们在使事情尽快运行方面做得很出色，Grails和Groovy团队非常，非常敬业。

我完全和你在一起！Grails的边缘感觉仍然很粗糙，以至于和Rails相比简直是开玩笑。如果至少错误报告要好一点。但是我想这也可能是由于它在幕后使用了大量的库。一句话：stacktrace！我也不是喜欢model-> db方法（Rails具有db-> model）。脚手架还留有很大的改进空间。然后，“无需重新启动”也将无法正常运行。（我不确定更糟糕的是-必须一直重新启动，或者有时会发现奇怪的行为在重新启动时消失了）并且不要让我开始使用GORM。（当需要花费数小时才能找到简单的SQL方法时，您会开始怀疑整个ORM是否真的为您节省了时间），只要很简单。

我的意思是：当您来自Java世界时，它仍然是框架的更好选择之一。（有很多无用的废话，自称为Web框架）...它有潜力。我只是希望它不会建立在许多其他复杂内容之上。

无论如何-我们希望这些事情能得到解决。目前，我潜伏在playframework.org上，该网站看起来也非常光鲜而且很有前途。

当他们完成eclipse插件时，这将是值得的。我说越早越好。在这种情况发生之前，试图向我的老板推销杂技并非易事。

我发现Grails的最大优点是，我不必再关心数据库了-模式是自动创建/更新的，并且持久性在很大程度上由我完成（不再编写SQL查询）。这是一个巨大的解脱。另一个很好的事情是，一旦您确定了控制器和视图的模板，添加新域对象的速度就非常快。尽管我怀疑您至少会为您的视图进行持续的更改，然后将其重新调整为现有的视图。

至于IDE-似乎IntelliJ是最好的选择，但是我很高兴使用Netbeans 6.5。我将MyEclipse用于其他所有开发，但是Netbeans现在具有更好的Grails支持。

在开始使用Grails之前，我是Eclipse用户。很快很明显，这不会削减它。所以我尝试了Intellij和NetBeans。当时，就Groovy和Grails而言，Intellij更好。但是，NetBeans是免费的，这对我来说已经足够了。从那以后，这三个公司都发布了新版本或新插件。由于Intellij的成本，我仍在使用NetBeans。随着Spring Source收购G2One，人们的期望之一是在Eclipse中对Groovy和Grails的更多支持。这对于增加采用率是必要的。

将Grails用于新项目真是太好了。因此，不再需要太多的Enterprise Java包。我可以想象尝试移植某些东西会很困难，因为在您了解框架的优缺点所在之前，很难有效地利用它。可以肯定的是，在Grails 1.1中，对JSP的支持将变得更加容易，我不知道在尝试使用新框架时使用beta版本是否是个好主意。该测试还通过了新版本的重大修订。如果时间允许，您可以考虑等待，因为1.1版本应该很快。

如果您有机会在从头开始项目时尝试在不同的IDE中尝试Grails，那么我认为您会以不同的眼光看待它。

我刚刚开始在新项目上使用grails ...不必编写任何xml文件，但仍然具有Spring和Hibernate的功能，这的确令人惊叹。

虽然将IntellijIDEA用于IDE，但实际上我是通过IDE发现Grails的（我可能会偏颇，我讨厌日食）。

完全。Java框架太多了，新手的门槛就很高了，这证明了Grails能够在如此拥挤的空间中脱颖而出。

它仍然有一些尖锐的边缘，但是这些边缘消散只是时间问题，基础项目非常值得。

对于您的应用程序类型，Grails可能会很大（基于它在第一次初始化时创建的大量文件以及所占用的资源）。如果您正在寻找简单的东西，Grails可能不是您想要的东西。如果您正在寻找简单实用的东西，到目前为止，我认为django可以很好地完成您的工作。看一看从教程创建CRUD应用程序的简单程度（需要多少文件）。从这里开始，您的应用程序可以（相对）轻松地随您的需求和要求的增长而扩展。

我不确定他们是否能够使您知道的Grails正确。正确地说，我的意思是说所有细节（小细节和大细节），最终使它变得脆弱而脆弱。我什至不知道背后是否有真正的开发团队（意味着2个以上的人员）。

每当我遍历Grails项目的某个功能，尝试改进某项功能时，它都是相同的工作流程：一切都崩溃了，然后是一百个“ google”测试周期，然后找出无法执行的原因您想要什么，然后做其他事情。

最后，您感到沮丧，因为您甚至不想触摸任何运行的东西。还有一些不好的事情，您将其丢弃！

我正在考虑通过JRuby切换到Rails。这可能是两全其美的：功能强大的Web框架，活跃的社区和庞大的开发团队，专门的开发团队，不基于可疑且复杂的框架（如Spring或Hibernate）的平台，快速而雄心勃勃的发布周期。还有JRuby，因为坦率地说，背包里有那么多Java资产，我不能就把它们扔掉。

如果您说的是Java方面的专长。您应该看看Play框架-这是一个受Ruby on Rails启发，开发周期非常短的Web框架-只需保存Java源文件并更新Web浏览器即可。而且，如果您想尝试另一种语言，Play Framework的模块可以让您改用Scala。

我喜欢Play Framework，因为它易于理解并且性能良好。如果需要，还可以将JPA和Hibernate用于ORM层。