5

我一直在研究诸如 Rails、Grails 等 Web 框架。我习惯于在 Spring Framework 中使用 Hibernate 来做应用程序……我想要一些更有效率的东西。

我意识到的一件事是，虽然 Grails 中的某些东西很性感，但它存在一些严重的问题。Grails 的控制器：

1）执行得非常好。它们似乎无法在运行时从超类扩展。我尝试这样做来添加基本操作和辅助方法，这似乎导致 grails 爆炸。

2）基于过时的请求参数模型（而不是表单支持对象，后者要好得多）。

3）很难测试。命令对象的处理方式完全不同......实际上编写测试比编写控制器代码要困难得多。

4) 命令对象的操作完全不同。它们是预先验证和绑定的，这与基本参数模型相比会导致很多不一致。

5) 命令对象不可重用，重用域类中的大部分内容（如约束和字段）在后面很痛苦。这在基本的 Spring 中是很简单的。为什么在 Grails 中做这件事不简单？

6）生成的脚手架是纯粹的废话。它没有概括插入和更新......它实际上在两个视图中复制/粘贴一堆代码：create.gsp 和 edit.gsp。这些观点本身就是一大堆小狗要做的事情。它使用低级参数而不是对象这一事实进一步加剧了这种情况。

集成测试比 Spring 集成测试慢 30 倍。真恶心。

一些模拟测试很难编写，并且在部署时不能保证工作，我认为它不鼓励快速的 tdd 测试周期。

大多数事情在运行时似乎都搞砸了，比如添加标签库或其他任何东西。服务器重启问题根本没有解决。

我开始认为使用 Spring/Hibernate/Java 是唯一的方法。虽然启动时成本相当高，但我知道它最终会平稳下来。

很糟糕，我不能使用像 Scala 这样的语言......因为习惯上，它与 Hibernate 是如此不兼容。

这个应用程序也不是数据库上的普通 UI。它有一些，但它不会是一个懒散的。我现在非常害怕 Grails，因为它在 Controller 层中是多么的垃圾。

关于我能做什么的建议？

4

4 回答 4

4

您可以查看Play！框架。我目前正在研究 grails 中的一个应用程序，该应用程序似乎进展顺利，并且对 play 框架并没有真正做太多，因此它可能适合您，也可能不适合您。Play 框架最近新增的功能之一是 Scala 模块，它允许您在 Scala 中编写代码。

于 2010-05-30T01:20:27.407 回答
3

所有抽象都泄漏。你在相反的一面为圣杯命名了六个项目。一个给春天。看来，你更喜欢 Spring，那么。

于 2010-05-29T23:56:17.407 回答
1

我开始认为使用 Spring/Hibernate/Java 是唯一的方法。虽然启动时成本相当高，但我知道它最终会平稳下来。

然后也许看看Spring Roo（也阅读Grails vs Roo - 为什么 SpringSource 正在推动两种非常相似的技术？）。

于 2010-05-30T02:01:19.073 回答
1

在过去的一年中，我在几个项目中使用了 Grails，发现开发效率的提高远远超过了缺点，而且我还没有发现我无法解决的缺点。

关于您的一些具体反对意见：

1）执行得非常好。它们似乎无法在运行时从超类扩展。我尝试这样做来添加基本操作和辅助方法，这似乎导致 grails 爆炸。

FWIW，我从来没有觉得需要从基类扩展控制器。每个控制器都支持不适合重用的特定 HTTP 调用，并且任何需要重用的东西都可以/应该委托给服务。

2）基于过时的请求参数模型（而不是表单支持对象，后者要好得多）。

同样，FWIW 这对我来说不是问题。Grails 将所有参数很好地打包到一个 Map 中，这就是我通常需要的。如果我需要更多，我会创建一个 Command 对象，这非常简单。

3）很难测试。命令对象的处理方式完全不同......实际上编写测试比编写控制器代码要困难得多。

是的，在 grails 中进行测试是它的低点之一。我完全放弃了 Grails 测试工具，只使用 Selenium 通过 GUI 进行自动化测试。不理想，但对我们来说效果很好。

6）生成的脚手架是纯粹的废话。它没有概括插入和更新......它实际上在两个视图中复制/粘贴一堆代码：create.gsp 和 edit.gsp。这些观点本身就是一大堆小狗要做的事情。它使用低级参数而不是对象这一事实进一步加剧了这种情况。

实际上，我发现脚手架对入门非常有帮助。它永远不会以原生形式投入生产（偶尔内部应用程序除外），但它可以节省大量时间开始开发应用程序的基本构建块。此外，如果您不喜欢提供的脚手架模板，您可以随时创建自己的脚手架模板。

集成测试比 Spring 集成测试慢 30 倍。真恶心。

一些模拟测试很难编写，并且在部署时不能保证工作，我认为它不鼓励快速的 tdd 测试周期。

同样，是的——测试不是 Grails 的强项。

大多数事情在运行时似乎都搞砸了，比如添加标签库或其他任何东西。服务器重启问题根本没有解决。

自 1.2 发布以来，我在这方面没有任何问题。这是我使用过的最干净的运行时更改环境。当然有些事情需要重新启动（例如引导模块），但对于大多数开发阶段来说，它工作得很好。

我开始认为使用 Spring/Hibernate/Java 是唯一的方法。虽然启动时成本相当高，但我知道它最终会平稳下来。

不仅在启动时，而且在整个开发过程中。我猜我正在与之合作的团队正在以 3-5 倍的速度生产可用于生产的功能，这是我们使用“传统”框架所能达到的速度。它当然不适合每个人和每个项目，也不是完美的，但如果您的项目符合 Grails 的优势，它可以成为一个巨大的加速器。除此之外，您可以在很大程度上挑选和选择要使用多少 Grails（而不是根据需要利用 Spring/J2EE 层），我将其视为“有你的蛋糕，也吃它”的选项。我的2c。

于 2010-06-15T15:26:30.117 回答