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

Posted 2023-05-07

【中文标题】什么网络平台适合我？ [关闭]

【英文标题】：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] 。

【参考方案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。