什么网络平台适合我？ [关闭]答案

【问题标题】：What web platform is right for me? [closed]什么网络平台适合我？ [关闭]
【发布时间】：2011-02-25 14:09:10
【问题描述】：

我一直在研究 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 层中是多么的垃圾。

关于我能做什么的建议？

【问题讨论】：

“很糟糕，我不能使用像 Scala 这样的语言......因为习惯上它与 Hibernate 非常不兼容。” - 有趣，您能详细说明一下吗？
基本上，因为很多 spring/hibernate 方法接受或返回对象，你必须在你的代码中做很多 asInstanceOf[Bleh]。 scala 集合和 java 集合之间也存在不匹配，因此您需要添加一些额外的膨胀来转换它们。还有一个表现呢。使用注释时，scala 需要在每个参数周围使用 Array(...)，因为它没有内置在 systax 中的单元素异常...这使得一些事情变得更加臃肿。
为什么要使用 instanceof ？为什么不添加有关对象类型的信息？
用 hibernate 试试 - 它不会工作。 Hibernate 和 Spring 有各种方法接受 Object 并返回 Object....所以如果你正在制作静态类型的方法，你必须对每个返回值执行 asInstanceOf[MyType] 。

标签： spring grails platform

【解决方案1】：

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

【讨论】：

【解决方案2】：

All abstractions leak。你在相反的一面为圣杯命名了六个项目。一个给春天。那么，您似乎更喜欢 Spring。

【讨论】：

【解决方案3】：

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

那么不妨看看Spring Roo（另请阅读Grails vs Roo - why SpringSource is pushing two very similar technologies?）。

【讨论】：

是的，但即使在演示中，事情也失败了……所以我不知道。我也讨厌 eclipse，而且我知道我不需要使用 eclipse，但是我上次尝试让 Roo 与 IDEA 一起工作时，这是不行的。我也不喜欢原始的jsp。我现在正在考虑在 scala 中做这个项目的想法。

【解决方案4】：

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

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

1) 执行得非常好。他们不似乎可以从 super 延伸运行时的类。我试过这个添加基本动作和辅助方法，这似乎导致圣杯爆炸起来。

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

2) 基于过时的请求参数模型（而不是形式支持对象，这是很多更好）。

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

3) 很难测试。命令对象被完全不同的对待......和实际上写起来要困难得多测试比写控制器代码。

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

6) 生成的脚手架是纯粹的废话。它不概括插入和更新...实际上将一堆代码一分为二复制/粘贴视图：create.gsp 和 edit.gsp。这观点本身就是巨大的一堆小狗做的事。这是进一步由于它使用低级参数而不是对象。

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

集成测试比测试慢 30 倍一个 Spring 集成测试。它是恶心。

有些模拟测试太难了写，不保证工作当它被部署时，我认为它不鼓励快速的 tdd 测试周期。

再次，是的，测试不是 Grails 的强项。

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

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

我开始考虑 Spring/Hibernate/Java 是唯一的方法去。虽然有一个相当大启动成本，我知道它会最终平滑。

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

【讨论】：