我一直在研究像Rails，Grails等网页框架。我习惯在Spring Framework中使用Hibernate做应用程序......我想要更高效的东西。
我意识到的一件事是，虽然Grails中的一些东西是性感的，但它有一些严重的问题。 Grails的控制者：
1）实施得非常好。它们似乎无法在运行时从超类扩展。我试着添加基本动作和辅助方法，这似乎会导致grails爆炸。
2）基于一个过时的请求参数模型（而不是形成支持对象，这是更好的）。
3）很难测试。命令对象的处理方式完全不同......实际上编写测试比编写控制器代码要困难得多。
4）命令对象的操作完全不同。它们经过预先验证和绑定，与基本参数模型相比会导致很多不一致。
5）命令对象不可重复使用，后端很难重用域类中的大部分内容，如约束和字段。这是在基本的春天做的TRIVIAL。为什么在Grails中做到这一点并不容易？
6）生成的脚手架是纯粹的废话。它没有概括插入和更新......它实际上在两个视图中复制/粘贴一堆代码：create.gsp和edit.gsp。这些观点本身就是大堆的狗狗。由于它使用的是低级参数而不是对象，因此更加复杂。
集成测试比Spring集成测试慢30倍。这很恶心。
一些模拟测试很难编写，并且在部署时无法保证工作，我认为它会阻碍快速的测试周期。
大多数事情似乎都会在grails运行时搞砸，比如添加一个taglib，或者其他任何东西。服务器重启问题根本没有解决。
我开始认为使用Spring / Hibernate / Java是唯一的方法。虽然启动时的成本非常高，但我知道它最终会平稳下来。
很糟糕我不能使用像Scala这样的语言...因为惯用，它与Hibernate不兼容。
此应用程序也不是数据库中的普通UI。它有一些，但它不会是一个懒散。我现在对Grails感到害怕，因为它在控制器层中是多么糟糕。
关于我能做什么的建议？
答案 0 :(得分：4)
您可以结帐Play! framework。我目前正在开发一个grails的应用程序，似乎进展顺利，并没有真正完成游戏框架，因此它可能适用于您，也可能不适合您。 Play框架的最新成员之一是Scala模块，它允许您使用Scala进行编码。
答案 1 :(得分：3)
<强> All abstractions leak 即可。你在对侧标明六个项目的grails。一个春天。看来，你更喜欢春天。
答案 2 :(得分：1)
我开始认为使用Spring / Hibernate / Java是唯一的方法。虽然启动时的成本非常高，但我知道它最终会平稳下来。
然后可以查看Spring Roo（也请阅读Grails vs Roo - why SpringSource is pushing two very similar technologies?）。
答案 3 :(得分：1)
过去一年，我在几个项目中一直使用Grails，发现开发效率的提升远远超过缺点，而且我还没有找到一个我无法解决的问题。
关于您的一些具体反对意见：
1）实施得非常好。他们没有 似乎能够从超级延伸 运行时的类。我试过这个 添加基本动作和辅助方法， 这似乎导致grails吹 起来。
FWIW，我从未觉得需要从基类扩展控制器。每个控制器都支持不能重复使用的特定HTTP调用，任何需要重用的东西都可以/应该委托给服务。
2）基于过时的请求 参数模型（而不是形式 支持对象，这是很多 更好）。
同样，FWIW这对我来说不是问题。 Grails将所有参数很好地打包到Map中，这是我通常需要的。如果我需要更多，我创建一个Command对象，这非常简单。
3）很难测试。命令对象 对待完全不同...... 写它实际上要难得多了 测试比写它 控制器代码。
是的 - 在grails中测试是其中一个低点。我完全放弃了Grails测试工具，只需使用Selenium通过GUI自动化测试。不理想，但它对我们来说很好。
6）生成的脚手架 是纯粹的废话。它没有概括 插入和更新......实际上 将一堆代码复制/粘贴到两个中 views：create.gsp和edit.gsp。该 观点本身就是巨大的堆积 小狗的事。这是进一步的 它使用的事实更加复杂 低级参数而不是对象。
我实际上发现脚手架在入门时非常有帮助。它永远不会以它的原生形式生产（除了偶尔用于内部应用程序），但它可以节省大量时间开始开发应用程序的基本构建块。此外，如果您不喜欢提供的脚手架模板，您可以随时创建自己的脚手架模板。
集成测试比30倍慢 一个Spring集成测试。它是 恶心。
一些模拟测试很难 写，不保证工作 当它被部署时，我认为它 不鼓励快速的tdd测试周期。
再次，是的 - 测试不是Grails的强项。
大多数事情似乎搞砸了grails 当它正在运行时，就像添加一个 taglib，或任何真的。服务器 重启问题根本没有解决。
自1.2发布以来，我在这方面没有任何问题。这是我工作过的最干净的变化 - 运行环境。当然有一些东西需要重启（例如mods到bootstrap），但是对于大多数开发阶段来说它都很有效。
我开始考虑与之相伴 Spring / Hibernate / Java是唯一的方法 去。虽然有一个非常大的 启动时的成本，我知道它 最终顺利。
不仅在启动时，而且在整个开发过程中。我猜我正在使用的团队正在以比我们使用“传统”框架更快的速度生成3-5倍的生产就绪功能。它肯定不适合每个人和每个项目，并且它并不完美，但如果你的项目符合Grails的优势，它可能是一个巨大的加速器。除此之外，您可以在很大程度上挑选并选择您想要使用的Grails（如果您需要，可以使用Spring / J2EE图层），我将其视为“有你的蛋糕，也可以吃它”选项。我的2c。