这是半咆哮,半问题.
是否值得使用Grails？我正在尝试开发一个相对简单的数据库驱动的Web应用程序.我的专长是Java,所以Grails自然是个不错的选择.起初我想过使用Spring,JPA和Hibernate,但我之前已经使用过它,并且遇到了各种繁琐的配置和编码工作.Grails称自己为解决这个问题.
我对Grails最大的挫败感是所有不起作用的小事.我的意思是,它不会像人们直觉认为的那样起作用.边缘非常粗糙.我经常遇到问题.有时这是我缺乏Grails的理解 - 有时候我发现了合法的Grails错误.
一个主要问题是缺乏良好的Eclipse集成.有一个Groovy和Grails插件,但除了语法高亮之外它没有什么作用.从Java调用Groovy,反之亦然,配置非常痛苦.没有良好的IDE支持是一个主要的失败.
发生的事情是我坐下来尝试开发我的Web应用程序.在一天结束时,我意识到我花了大约85%的时间调试与Grails相关的问题.如果不是Eclipse的问题,那么它的预先加载,在视图中获取,一个一对多的关系,怪异的空文件的错误行为,怪异的财产/消气错误 -它只是不停去.这只是我今天遇到的问题的一个例子.我与Grails的最后一次坐下来产生了许多不同的问题.
我有时想知道它是否值得.我很好奇其他人是否经历过这种情况.是否有人真正使用Grails来高效地创建Web应用程序？是否还有其他我需要考虑的快速Web开发框架？
我们有一个由12名经验丰富的高级Java开发人员组成的团队,他们从0.6B学习Grails,我们仍然在研究基于Grails的项目.我不会心甘情愿地回到Java,我们都松了一口气,打破了如何使用Grails应用程序快速到达某个地方.
这是一场斗争,这并不容易,而且有挫折感.
然而,鉴于我们不断努力,我们很快就提供了一些东西.有些漏洞,很多都有解决方法.
我听说过几个擅长Java的开发人员尝试深入研究Grails项目的复杂咒语.我们避开了所有的Java并且去了纯Grails和Groovy.我们确保我们开始简单,尽可能地管理和尽可能地构建复杂性.我们不敢深入研究,并希望我们的Java知识足以带给我们.
我们最终创造了一些巨大而复杂的东西,它的工作非常出色,并且比编写纯Java/Spring/Hibernate版本更快; 并且没有像样的IDE支持,而且在bug方面比现在更糟糕.
关于Eclipse支持,唯一真正用于Grails/Groovy的IDE是Intellij - 遗憾的是Eclipse支持:我是一个Eclipse爱好者并且远不是一个Intellij转换 - Grails/Groovy支持将其他所有东西都吹走了虽然.
是的,Grails与Spring相比还不成熟.或者Hibernate.而且我敢打赌,在他们存在的前1.5年里,他们同样充满了问题.
这就是它,将责任放在你身上,注意你将复杂性保持在最低限度,仔细测试(在我们看来)并逐渐和谨慎地建立复杂性.
一旦在堆栈中涉及Spring/Hibernate,就没有Java的快速代码解决方案.Grails所体现的复杂性反映了Spring/Hibernate自身的复杂性.如果你觉得用纯Java做你的时间会更好,我不会反驳.我仍然有我的WTF但现在陡峭的学习曲线已经落后于我,我想我会坚持更多的Grails.
我非常喜欢写grails应用程序有两个原因:
我不必使用Java
我可以使用Java
我认为在熟悉grails之后,可以非常快速和优雅地完成他的工作.
对于好的方面来说太多了.负面的是性能,这在两个方面打击了我:部署和测试驱动开发.
我没有设法在单个(租用)服务器上运行超过3个grails应用程序,因为我很快就达到了内存和性能限制.包含太多框架.
此外,grails的测试人员不值得这个名字.当我进行单元测试时,它们应该在瞬间完成,而不是在10到20秒内完成.所以我发现自己一直在用普通的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和java在服务层上使用spring.它是经典的三层(Web,逻辑,数据),其中Web是grails,逻辑是用java实现的.与java中一样,我们使用bean对象来表示不同层之间的数据.
它工作得很好,它是我们案例的最佳解决方案,因为bean对象已经存在,以及数据库结构.根据我们的经验,我认为grails作为Web表示层具有很大的价值,但我会坚持使用java编写业务规则并持久保存应用程序数据 - 因为grails"是"java,所有grails-java集成都很漂亮直截了当.
人们在这里说,我们使用eclipse来开发grails应用程序并且它的集成很差.但是,作为其他开发人员的建议,我们从命令行运行grails应用程序,并且只使用eclipse来保存源文件,并且它可以很好地工作,因为应用程序可以即时更新.
我在其他地方使用grails而不是在表示层中感觉不舒服.
我完全和你在一起!Grails仍然感觉边缘粗糙,将它与Rails进行比较几乎是一个笑话.如果至少错误报告更好一点.但我想这可能也是因为它使用了大量的库.一个字:stacktrace!我也不是模型 - > db方法的忠实粉丝(Rails有db-> model).脚手架也留有很大的改进空间.然后"不需要重新启动"也不像宣传的那样工作.(我不确定更糟糕的是 - 不得不一直重新启动或者有时会发现当你重新启动时会消失的怪异行为)并且不要让我开始使用GORM.(当需要几个小时才能找到一种简单的SQL方法时,你会开始怀疑整个ORM是否真的能节省你的时间)也许只要它很简单.
我的意思是:当你来自java世界时,它仍然是框架的更好选择之一.(那里有太多无用的垃圾,称自己为网络框架)......它有潜力.我只是希望它不会建立在其他复杂的东西之上.
无论如何 - 让我们希望这些东西得到分类.目前我潜伏在playframework.org,这看起来非常光滑和有前途.
我在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团队都非常非常专注.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
