Grails值得吗?

这是一半的咆哮,一半的问题。

值得使用Grails吗? 我试图开发一个相对简单的数据库驱动的Web应用程序。 我的专长是Java,所以Grails自然是一个不错的select。 起初我想过使用Spring,JPA和Hibernate,但是之前我曾经使用过,并且遇到了各种繁琐的configuration和编码工作。 Grails宣称自己正在解决这个问题。

我对Grails最大的挫折是所有不起作用的小事情。 我的意思是,它不会像直觉上认为的那样工作。 边缘很粗糙。 我不断遇到问题。 有时候是因为我缺乏对Grails的理解 – 有时我发现了合法的Grails错误。

一个主要的问题是缺乏良好的Eclipse集成。 有一个Groovy和Grails插件,但除了语法高亮之外,它没有什么其他function。 从Java调用Groovy,反之亦然是非常痛苦的configuration 。 没有良好的IDE支持是一个主要的失望。

我坐下来试图开发我的Web应用程序会发生什么? 在这一天结束的时候,我意识到我已经花了大约85%的时间来debugging与Grails相关的问题。 如果这不是Eclipse的问题,那么它是加载 , 视图中获取, 一对多的关系 , 奇怪的空文件错误的行为 , 一个奇怪的属性/ getter错误 – 它只是继续下去。 这只是我今天遇到的一些问题。 我最后一次与Grails坐在一起,产生了一大堆不同的问题。

我有时会怀疑它是否值得。 我很好奇,如果别人经历了这一点。 有没有人真正使用Grails来高效地开发Web应用程序? 有没有其他的快速网站开发框架,我应该考虑?

我们有一个12人的团队,他们都是经验丰富的高级Java开发人员,他们从0.6B开始学习Grails,我们仍然在开发基于Grails的项目。 我不愿意回到Java,我们都很高兴能够打破如何使用Grails应用程序快速获取某个地方的信息。

这是一场斗争,这并不容易,有挫折感。

不过,考虑到我们正在进行的努力,我们很快就做出了一些事情。

我听说过好几位擅长Java的开发人员尝试深入Grails项目的复杂咒语。 我们避开了所有的Java,进入了纯粹的Grails和Groovy。 我们确保我们开始简单,尽可能以可pipe理和实际的方式构build复杂性。我们不敢潜入最深处,希望我们的Java知识足以承载我们。

我们最终创造了一些巨大而复杂的东西,它的function非常出色,比编写纯Java / Spring / Hibernate版本的速度快得多。 那就没有像样的IDE支持,而且错误的情况比今天更糟糕。

关于Eclipse的支持,唯一真正用于Grails / Groovy的IDE是Intellij– Eclipse的支持很落后,可悲的是:我是一个Eclipse的爱好者,远不是Intellij的转换 – Grails / Groovy的支持把所有的东西都带走虽然。

是的,Grails与Spring相比可能还不成熟。 或者hibernate。 我敢打赌,在他们存在的头一年,他们同样充满了问题。

就是这样,把责任放在你身上,照顾你把复杂性降到最低,小心地先testing(在我们看来),逐步小心地逐步复杂化。

一旦将Spring / Hibernate包含在堆栈中,Java就没有快速的代码解决scheme。 Grails所体现的复杂性反映了Spring / Hibernate自身的复杂性。 如果你觉得你花时间用纯Java做的更好,那么我就不会争辩了。我还有我的WTF,但是现在这个陡峭的学习曲线在我身后,我想我会再坚持一下Grails。

我非常喜欢写Grails应用程序,原因有二:

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

我认为,在熟悉Grails之后,我们可以非常快速,优雅地完成他的工作。

非常好的一面。 负面的是性能,这在两个方面打击我:部署和testing驱动的发展。

我还没有设法在单个(租用)服务器上运行3个以上的grails应用程序,因为我很快就遇到了内存和性能限制。 包含的框架太多了。

另外,Grails的testrunner不值得这个名字。 当我运行unit testing时,应该立即完成,而不是在10到20之间。 所以我发现自己一直在用普通的java编写业务逻辑,因为我可以更快地testing它。 但我想这可以通过更好地集成到IDE(日食)来解决。

我认为Spring对Grails的支持将会是一个很大的提升。 如果有人能通过networking上的CRUD移动它,那就是那些人。

我也认为它正在达到一个临界质量。 2009年将有好几本新书上市。我认为这些将有助于采用率。

我完全同意原来的海报情绪。

我们是一家Java + Spring商店,并借此机会试用了Grails。 我们首先创build了一个非常小的testing应用程序,结果非常简单,它工作得很好。 我们在这里遇到的主要问题是由于我们对Groovy和Grails缺乏知识。

在成功之后(信心提升),我们决定尝试一个稍大的项目。 这是一个更加痛苦的经历。 正如其他人所说,我们已经发现了各种各样的表面上并不直接performance出来的错误和问题。 应用程序的重新启动周期变得非常痛苦,除非你有非常好的testing覆盖率,否则这是做任何重新分解的噩梦。

真令人沮丧的是没有一个错误信息的代码失败! 它只是不起作用,你不知道为什么?

我喜欢JMS,Quartz和Remoting等插件的易用性。 消除了很多乏味的XML。

我很喜欢GORM,虽然我们也有几个问题。

我不喜欢Groovy的松散types的性质,以及为了能够捕获一堆错误而必须运行应用程序的事实,这让我想起了太多的PHP或Rails。

在这一天结束的时候,我们正在问自己是否有可能使用Grails编写一个复杂的可pipe理软件。

我们有一个即将投入生产的Grails应用程序,所以我们将会看到。

我们在web层+ java上使用grails +,在服务层上使用hibernate和spring。 这是经典的三层(networking,逻辑,数据),其中Web是Grails,逻辑是用java实现的。 和java一样,我们使用表示不同图层之间数据的bean对象。

它工作得非常好,对于我们的情况来说,这是最好的解决scheme,因为bean对象已经存在,还有数据库结构。 根据我们的经验,我认为grails作为web表示层有很大的价值,但是我会坚持用java编写业务规则并坚持应用程序数据 – 就像grails“是”java一样,所有的grails-java集成都很漂亮直截了当。

正如人们在这里所说的,我们使用eclipse来开发Grails应用程序,这是一个糟糕的整合。 但是,作为其他开发人员的build议,我们从命令行运行grails应用程序,只使用eclipse来保存源文件,并且它运行得非常好,因为应用程序正在进行更新。

但是在表示层以外的其他地方使用Grails却感觉不舒服。

我完全和你在一起! Grails在边缘仍然感觉如此粗糙,以至于与Rails进行比较几乎是个玩笑。 如果至less错误报告好一点。 但是我想这可能也是由于它在封面下使用了大量的库。 一个字:stacktrace! 我也不是模型 – >数据库方法(Rails有db->模型)的大粉丝。 脚手架也留下了很大的改进空间。 然后“不需要重新启动”也不能像广告一样工作。 (我不确定更糟糕的是 – 不得不重新开始,或者有时会发现当你重新启动时会消失的怪异行为)并且不要让我开始使用GORM。 (当需要几个小时才能find一个简单的SQL,你会开始怀疑整个ORM是否真的节省了你的时间)也许只要它很简单。

我的意思是:当你来自Java世界时,它仍然是框架的更好的select之一。 (这么多没用的垃圾,自称是一个Web框架)…它有潜力。 我只希望它不会build立在其他复杂的东西之上。

无论如何 – 让我们希望这些东西得到sorting。 目前我正在潜伏在playframework.org ,这看起来也很光滑,很有希望。

在Ruby on Rails方面我比Java世界有更多的经验,所以我从另一个angular度来介绍。 总的来说,Grails比Rails更加粗糙,部分原因在于它不够成熟,部分原因在于它依赖于两个非常复杂的框架(Spring和Hibernate)。 Rails也有一个更大的社区。

但是,Groovy作为一种语言已经取得了长足的进步,并且很高兴与之合作。 感谢Groovy 1.6所做的改进,Grails比JRuby on Rails更快捷,并且通过GPath获得惊人的XML支持。 在JVM上有很多很好的function(比如并发性和线程安全代码),但是不用沉迷Java(一种我不太在意的语言),所以我真的说服自己在MRI上使用任何东西的困难时期。

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

至于你的Eclipse问题,我忍不住。 我使用Vim和Emacs,主要是因为我无法忍受使用IDE。 对于像Groovy,Ruby和Python这样的dynamic语言来说,我不认为IDE真的会带来任何好处,因为没有任何地方可以生成代码,也不需要编译。 也许尝试一下sans IDE一段时间,看看事情是否更顺利?

所以,是的,我认为Grails是值得的。 他们已经完成了尽可能快的工作,而Grails和Groovy团队都非常专注。

当他们完成eclipse插件时,这将是值得的。 越快越好,我说。 在这种情况发生之前,试图向我的老板推销Groovy并不简单。

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

使用Grails来开发一个新项目非常棒。 企业Java包的大部分已经不再需要了。 我可以想象,尝试移植一些东西是很困难的,因为直到你理解了框架的优缺点之后,很难有效地利用它。 我们承诺,在Grails 1.1中,JSP支持会变得更容易,我不知道在尝试构build新框架的时候使用beta版本是个好主意。 新版本的testing也经过了重大修改。 如果时间允许,你可以考虑等待1.1版本的发布。

如果您有机会在从头开始项目的时候尝试在不同的IDE中使用Grails,我想您会从另一个angular度看待它。

我发现Grails的最大优点是我不必再关心数据库了 – 模式是自动创build/更新的,持久性在很大程度上是为我完成的(不再需要编写SQL查询)。 这是一个巨大的安慰。 另一件相当好的事情是,一旦你在控制器和视图的模板上下定论,添加新的域对象是非常快的。 尽pipe我怀疑你至less会对你的观点做出持续的改变,但是回到现有的观点上来。

至于IDE – 似乎IntelliJ是最好的select,但我很高兴使用Netbeans 6.5。 我使用MyEclipse进行所有其他开发,但Netbeans现在只有更好的Grails支持。

我刚刚开始在一个新的项目中使用grails …不必编写任何xml文件,但仍然有Spring和Hibernate的力量是真正令人惊叹的。

尽pipeIDE使用IntellijIDEA,但实际上我通过IDE发现了Grails(虽然我可能会有偏见,但是我讨厌 eclipse)。

完全。 有那么多的Java框架,对于新手而言,该框架是相当高的,而且这是Grails的一个certificate,它能够在如此拥挤的空间中站稳脚跟。

它仍然有一些尖锐的边缘,但这些只是一个时间问题之前,他们被淘汰,底层项目是非常值得的。

对于您的应用程序types,Grails可能会很大(基于它在第一次初始化时创build的大量文件以及所需的资源)。 如果你正在寻找简单的东西,Grails可能不是你正在寻找的东西。 如果你正在寻找一些简单而有效的工具,那么我认为django可以很好的完成你的工作。 看看如何从它的教程创build一个CRUD应用程序是多么简单(它需要多less文件)。 从这里开始,随着您的需求和需求的增长,您的应用程序可以(相对)轻松扩展。

我不确定他们能否让Grails成为你所知道的。 而正确的意思是说明所有的细节(小的和大的),最终使它感觉脆弱脆弱。 我甚至不确定是否有一个真正的开发团队(意味着超过2人)。

每一次我迭代我的Grails项目的一个特性,尝试改进一些东西,它是一样的工作stream程:一切都崩溃了,然后是一百个“谷歌”testing周期,然后你找出你不能做的原因你想要什么,你做了别的什么。

最后,你很沮丧,因为你甚至不想触摸任何运行的东西。 而事情不好,你放弃他们!

我正考虑通过JRuby切换到Rails。 这可能是两全其美的:一个function强大的Web框架,拥有一个活跃的大型社区,一个专门的开发团队,一个不基于像Spring或Hibernate这样有问题和复杂的框架的平台,一个快速和雄心勃勃的发布周期。 而JRuby坦率地说,我的背包里有这么多的Java资产,我不能把它扔掉。

如果你的专长是用Java写的, 您应该看看Play Framework – 这是一个受Ruby on Rails启发并具有很短开发周期的Web框架 – 只需保存您的Java源文件并更新您的Web浏览器即可。 如果你想尝试另一种语言,Play Framework有一个模块,可以让你使用Scala。

我喜欢Play Framework,因为它很容易理解,性能也很好。 如果需要,也可以使用JPA和Hibernate作为ORM层。