我知道这是重复的,然而,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分钟即可启动.这是非常缓慢的.我已经恢复了文本编辑器(您会注意到所有在线教程视频也会这样做)和一些自定义语法hilighting.
我对性能有一些严重的担忧.有点太早说,但我已经发现自己因为休眠而调整了数据库.也许这是可以预料的,但我真的必须保持我的域模型简单的约定,以产生高性能的查询.
最后一个,您的逻辑域模型和您的物理数据库模型应该相同的约定不是一个明智的默认值,在现实世界中不太可能出现这种情况.我知道你可以将两者分开,但它会产生一定程度的复杂性,如果扩展惯例,我认为可以避免这种复杂性.没有足够的关于构图的文档以及您需要做些什么才能使它在实践中发挥作用.
我已经使用Grails超过4个月了,我将尝试给你我个人对Grails及其可用性的感觉.
Grails现在是否值得与Ruby或其他滚动你自己？
当然,答案不是"是"或"否",而是取决于.这取决于你的要求(你需要在Java世界吗？),你的偏好(你更喜欢面向域的开发,你更喜欢Groovy ......)？但是,我可以回答Grails是Rails的一个重要替代品.我相信无论你的Rails应用程序是什么,你都可以使用Grails.但是,根据项目的性质,可能需要更多或更少的时间.同样,如果您熟悉Rails但不熟悉Grails,那么Rails是更安全的选择.
它是否克服了它的错误开始？
是的.如果你看一下我最初的消息(在这个网站或其他网站上),我对Grails的bug很抱怨.但是,你只需要记住Grails在边缘有点粗糙(例如,不要过多地使用域继承),一旦你熟悉了框架,你就不会遇到太多不好的意外.我不是说Grails不是马车.它肯定不仅仅是Rails.而且,它比越野车更有用.一条建议:使用尽可能少的插件.因为它们中的许多都是马车,而且有些不兼容.所以,不要包括grails插件,除非你确定grails插件是最新的,非侵入式和测试(由你自己).
它真的能带来快速发展的好处吗？
是的.您几乎不需要处理数据库设计.由于Convention over Configuration,配置几乎从一开始就为您完成.您的应用程序很容易维护.我看到的唯一缺点是前端开发没有其他技术(如Rails或ASP)那么丰富
它是否适用于真实世界的制作应用程序？
我不能说因为我仍然没有访问我的网站,但我很自信,因为sky.com正在使用Grails,这些网站吸引了大量的流量 - 每天大约700万次页面浏览量.性能再次取决于您的应用程序架构和设计决策.
Eclipse插件是否比它更好并且适合用途？
不知道.我正在使用IntelliJ,但我想根据我在Grails领域看到的抱怨消息,它比一年前好多了.
我希望它有所帮助.
最近开始了一个Rails项目,一直在用Grails做一些事情.
Rails的主要内容是有很多东西对开发人员完全不透明(我讨厌),当你开始添加更多的插件/生成器/库 /等时,这往往会增加,因为为了将它们组合起来你需要修补一些东西.如果使用插件+版本的错误组合,你会感觉rails +插件只是一个巨大的DSL黑客攻击.
使用Grails,虽然生态系统要小得多,但一切都趋于相对一致.DSL方法并不常用,通过使用传统但无聊的设计(我的意思是使用类,接口等而不是DSL),更容易理解管道的工作原理.
进行一对一的比较,这是它的方式:
语言实现:我更喜欢Ruby而不是Groovy,尽管我不太了解Ruby.Groovy感觉就像一个好意图 - 糟糕的实现语言,其中一些功能被焊接在语法之上.我指的是一些特殊的类似乎只允许一些黑客攻击.
框架特点:Rails在这一方面遥遥领先.您可以通过多种方式配置Rails的大多数方面(例如:布局,模板,css/js打包器,验证,测试框架等).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风格的数据库,请使用Rails.此外,Ruby作为一种语言非常优雅
如果您喜欢类接口设计而不是DSL,那么更喜欢通过模型对应用进行建模,不需要精致的功能并熟悉Java生态系统,请使用Grails
这非常值得!
我们在几个项目中使用Grails,所有项目都取得了巨大的成功,原因如下:
简单 - 这是我们使用过的最简单的框架之一
遗留代码重用 - 我们所要做的就是获取遗留代码并将其放在lib或src文件夹中并完成.对我们来说很棒.
传统数据库结构 - 如果您想在旧数据库上生成数据可视化,这是一个很棒的工具.
现在,关于可行性:
错误:自1.1版本以来我们没有遇到太多错误(版本1.0对我们来说太麻烦了)
工具:Netbeans在这方面确实有所改进,但它甚至还没有像Intellij IDEA这样的其他工具(非常支持!).关于Eclipse也可以这么说.
可移植性:我们的项目从未遇到任何问题.
我们现在有6个Grails应用程序正在生产中,虽然Grails与java框架不同并且需要一些学习时间,但它已经得到了回报,因为我们使用了敏捷技术.细节:
我们使用IntelliJ.它不是很贵,而且几个星期后我们已经收回了.
对于所有动态语言代码,自动化测试,持续集成和重构是必须的.如果你已经练习过TDD或者至少有一个不错的测试代码覆盖率,那么它就不会增加额外的工作量.
Hibernate默认使用Grails,但您可以使用其他持久性框架.今天有5种持久性插件可用
在Graeme Rochers看来,测井显然不是一个问题,但它已经稳步改善.我没有遇到过没有记录错误的问题(你必须确保在代码中正确捕获异常)
调试显然不在雷达上(但这没有改进).无论如何我们不依赖于调试.
这就像所有新技术一样,我建议制作原型,代码评论,配对编程,也可以使用一些咨询.
这非常值得.我已经使用它超过一年了,并且喜欢它.我过去常常回避这些类型的rad工具,但它改变了我的工作方式.随着1.2版本的发布,它可以获得更好的堆栈跟踪信息(特别是对于GSP).
我在缩放方面遇到的唯一问题是hibernate和它的缓存,这实际上不是grails问题.即使是那些我一般不喜欢休眠的人,Grails用GORM包装它的方式对我来说也是一件艺术品.标准关闭方面非常适合使用.
我还没有找到一个熟悉Grails和Rails并且喜欢Grails的人.
如果你们都很了解,那么你几乎肯定更喜欢Rails.
Grails通常会吸引那些担心平台变化的Java开发人员.
在这种情况下,我认为JRuby可能是一种更好的方法,可以在老化的传统jvm上采用敏捷方法.
最近我将Grails用于项目,我希望与标准J2EE应用程序开发相比,分享我们的经验.
它真的能带来快速发展的好处吗？
当然,确实如此.即使脚手架路径提前离开并且约定覆盖了自己的需求,启动期也很短,因为我们不必关心许多不同的技术.这种轻量化使我们不仅工作更快,而且更精确和清洁.
编写标签从未如此简单 - 虽然使用JSF我们首先考虑是否值得付出努力,而Grails我们只是这样做.尽管不同的测试用例和模拟策略有时不一致且有缺陷,但为了实现testdriven并实现高覆盖率也很容易.
从Java切换到Groovy是一件非常愉快的事情,我们喜欢使用列表和地图文字,闭包,构建器,抛弃我们在Java中的锅炉板"map"实现,并编写紧凑,有意义且专注的代码.
降低开发速度的是不那么完美的IDE支持,这也适用于我们使用的IntelliJ插件.分散在不同地方的糟糕的,通常是旧的甚至是错误的文档(挫败了"搜索结束"的承诺)也阻碍了快速发展.所以我们经常不得不回到源代码阅读 - 后来被底层的Spring类层次结构吓到了.
京公网安备 11010802040832号 | 京ICP备19059560号-6 