关于 Glashammer App Engine Web 框架的意见答案

【问题标题】：Opinion about Glashammer App engine Web framework关于 Glashammer App Engine Web 框架的意见
【发布时间】：2010-02-17 19:08:59
【问题描述】：

我不得不查看一些代码并考虑在名为 Glashammer 的 Python 框架中工作。

我了解并喜欢 Django。我在 Appengine 上使用 Appengine 原生框架和 Django 有一些经验。

我想从您那里了解使用过其中一种或多种方法的人，Glahammer 如何与其他人进行比较和对比。有什么优点和缺点，还有什么我需要注意的。

【问题讨论】：

【解决方案1】：

我有很大的偏见，因为我是 Glashammer 的作者。但对我来说，优点是：

与 Django 之类的东西相比，我只想说“基于 Werkzeug，具有更好的插件框架。”

我有没有提到代码很漂亮，就像...的发光球体（哦，这可能是主观的）

【讨论】：

【解决方案2】：

经过一番谷歌搜索（并找到您的问题：）和半小时阅读文档和代码后，我可以这么说

Glashammer 很棒，因为它：

有据可查；
轻巧且非常灵活；
提供几乎所有东西来快速构建复杂的网络应用程序 - 与 Werkzeug 本身不同；
没有患 NIH 综合症，这可以说是 Django 最大的疣；
不强加与数据库相关的库，因此支持可以从 Python 使用的任何存储。 Django 仅支持一些关系数据库并假设您对它们感到满意。当然，你可以放弃 Django ORM，但这会使 admin——Django 的强项——毫无用处；
到目前为止，设备是定义视图的最佳方式。

Galashammer 不是很好，因为它：

与 Django 相比，开发历史更短，社区也更小，这导致：
- 不可避免地会降低核心代码的质量，并且
- 不可避免地会减少贡献代码的数量；
使用了一些可能不稳定的组件（例如处于 alpha 阶段的平原，虽然它是一个任意标签，可能与质量无关；而且，它仅用于 glashammer.utils.yconfig）；
不提供用于定义模型的 API（例如，一些带有后端的声明式包装器），因此应用程序的“可插入性”可能比 Django 中的要弱得多（应用程序会对环境做出太多假设）。

无论如何，我认为这个框架值得深入研究。

【讨论】：

感谢您的精彩总结。一点，关于 Glashammer 中的模型定义 API：如果您使用的是 RDBMS，您可能应该使用 SQLAlchemy 的声明式扩展，它几乎和 Django 一样简单，但是您会得到 SQLALchemy 的可爱之处。
我更喜欢具有后端特定字段/查询扩展的轻量级后端无关建模框架。这将提高“可插入性”。我正在为无模式数据库开发这样的东西 (pypi.python.org/pypi/pymodels)，但没有与 SQLAlchemy 集成的计划。在 Svarga 框架中可以看到一种更通用的方法，我认为它或多或少等同于 Glashammer。（尽管我为我的下一个应用选择了 Glashammer，因为它有更好的文档记录，并且允许从最小的工作代码开始，而不是在开始之前学习整个框架。）
...顺便说一下，可以在bitbucket.org/neithere/glasnaegel 中找到用于 Glashammer 的 PyModels 捆绑包 :) 我不确定我做的一切是否正确，但至少它可以工作。我还添加了一些快捷方式，如果您觉得它们值得添加，我希望在 Glashammer 中看到它们。