4

我需要您的建议来选择 Python Web 框架来开发大型项目：

数据库（Postgresql）将至少有 500 个表，其中大多数具有复合主键、大量约束、索引和查询。大约 1,500 次观看开始。该项目属于金融领域。总是有新的要求来。

ORM 会有帮助吗？

4

7 回答 7

12

Django 已被许多大型组织（华盛顿邮报等）使用，并且可以很容易地与 Postgresql 连接。我经常使用它并且没有遇到任何问题。

于 2009-06-16T18:26:09.903 回答
8

是的。ORM 对于将 SQL 内容映射到对象至关重要。

你有三个选择。

  1. 使用别人的 ORM

  2. 自己滚。

  3. 尝试执行低级 SQL 查询并从结果集中挑选出他们想要的字段。这实际上是一种 ORM，其映射分布在整个应用程序中。它执行起来可能很快并且看起来很容易开发，但它是维护的噩梦。

如果您首先设计表格，那么任何 ORM 都会很痛苦。例如，“复合主键”通常是一个坏主意，而使用 ORM 几乎总是一个坏主意。您需要有一个代理主键。然后，您可以拥有所有具有所需索引的复合键。他们只是不会是“主要的”。

如果您首先设计对象，然后制定将实现对象的表，那么 ORM 将是愉快的、简单的并且运行速度也很快。

于 2009-06-16T18:28:34.827 回答
5

由于您的大多数表都有复合主键，因此您需要一个支持该功能的 ORM。Django 的默认 ORM 不支持复合主键。SQLAlchemy 确实有这种支持（http://www.sqlalchemy.org/features.html）。

TurboGears 框架使用 SQLAlchemy 作为其默认 ORM。Pylons 也允许您使用 SQLAlchemy。

还有一些方法可以让 Django 使用 SQLAlchemy，尽管我自己没有尝试过。我更喜欢自己使用 Django，但考虑到您的需要，我会使用 Pylons 或 TurboGears，而不是在系统中硬塞不同的 ORM。

于 2009-06-16T19:12:15.647 回答
3

对于像 500 个表和 1500 个视图这样可怕的数据层复杂性，与大多数答案不同，我个人更喜欢坚持使用 SQL（PostgreSQL 提供了一个非常出色的实现，特别是在新的 8.4 版本中，如果你真的应该游说的话有机会）；我会[勉强]接受的唯一 ORM 是 SQLAlchemy（我不介意的少数 ORB 之一——但主要的附加价值是对不同 DBMS 的可移植性：如果你只致力于一个，并且在一个项目中这种数据库的复杂性你最好是这样，那么我个人的观点是任何ORM 都只是开销，因为数据访问层开发人员需要对特定的 DBMS 非常熟悉才能爬到可接受的性能）。

选择“原始 psycopg2”或 SQLAlchemy 作为我的数据访问层的技术，这将排除 Django（根据我的经验，它只适用于它自己的 ORM——但这不适合这种数据库复杂性的项目，IMNSHO ）。我个人会选择 Werkzeug，因为它是最适合需要大量灵活性和强大功能的高度复杂项目的框架——尽管如果团队只是不这样做，那么在它之上的 Pylons 和 Turbogears 2 作为后备可能是可以接受的不具备使用 Werkzeug 等灵活框架制作真正优美的音乐所需的网络应用程序经验和技能。

最后但并非最不重要的一点是，我强烈建议 Dojo 用于客户端的表示层 - 一个丰富且结构强大的 Javascript 框架，为“本地数据”、主机访问等提供出色设计的功能，并针对每个方面进行了优化。的几个浏览器（以及 Gears 等插件）可以提供，以及高级 UI 功能，似乎最有可能减轻后端团队的沉重开发负担（事实上，我强烈建议考虑提供一个本质上服务器端的 RESTful 接口，并将所有演示工作委托给客户端的 Dojo - 请参阅此站点更多，除了我会考虑 JSON 而不是 XML 作为首选的交换格式）。但是，我很容易承认，我对 UI 方面的了解远远少于对后端、业务逻辑和整体架构的了解，所以请看最后一段，看看它的价值！-)

于 2009-06-17T05:19:23.033 回答
2

根据您想要做的事情，您实际上有一些可能的框架：

[Django] 大、强（达到 python 框架的极限），并且在比赛中更老。被世界各地的一些“大”站点（[Django 站点]）使用。对于几乎所有内容以及不推荐使用的编码方法，仍然有点矫枉过正。

[Turbogears] 是基于 Pylons 的最新框架。对它了解不多，但是从尝试过的朋友那里得到了很多很好的反馈。

[Pylons]（Turbogears2 基于）。经常在“Python 的 PHP”上看到，它允许从头开始非常快速的开发。即使它看起来不适合大型项目，但它通常是更快、更容易的方法。

最后一个选项是 [Zope]（有或没有 Plone），但是 Plone 速度很慢，而且 Zope 学习曲线太长（甚至没有用 SQL 连接器替换 ZODB）所以如果你不知道框架，只是忘记它。

是的，对于这种规模的项目，ORM 似乎是必需的。对于 Django，您必须处理迁移到他们的数据库模型（不知道在 Django 中插入 SQLAlchemy 有多难）。对于 turbogears 和 Pylons，最合适的解决方案是 [SQLAlchemy]，它实际上是 python 最完整（和上升）的 ORM。对于zope ...好吧，没关系

最后但并非最不重要的一点是，我不确定您的项目是否有良好的开端。任何 python 框架上的 500 个表都会吓死我。像java（hibernate+spring+tapestry左右）这样无聊但死板的语言似乎真的更合适。

于 2009-06-16T18:55:24.300 回答
1

对于您所描述的内容，我绝对会推荐带有 SQLAlchemy 的 Repoze.bfg。我现在在 Django、TurboGears 1、TurboGears 2、Pylons 中完成了项目，并涉足了纯 Zope3。BFG 无疑是最适合以您一开始没有预料到的方式增长的项目的框架，但比 Grok 或 Zope 3 更轻量级和精简。此外，这些文档是所有文档中最好的技术文档其中，不是最简单的，但是那些回答你将遇到的难题的人是最好的。我目前正在做类似的事情，我们正在将一堆遗留数据库大修到一个新的 Web 可交付应用程序中，我们正在使用 BFG、一些 Pylons、Zope 3 适配器、用于模板的 Genshi、SQLAlchemy 和用于前端的 Dojo。我们对 BFG 非常满意，而且效果很好。BFG 类作为实际上是 zope 多适配器的视图，对于能够仅覆盖某些域资源的非常特定的位是绝对完美的。并且在任何地方都完全没有魔法全局变量，这使得测试和打包成为我们在任何框架中所拥有的最简单的方法。

嗯！

于 2010-02-11T18:29:58.047 回答
0

总是有新的要求来。

所以你真正需要的是一个能让你快速适应不断变化的规范的框架。

从个人经验来看，我只能讨论 django，它很棒，因为它可以让你快速启动和运行。

如果你坚持它的 ORM，你将很容易让你的模型充实并以有用的方式连接起来。您需要熟悉数据库迁移工具，因为 Django 没有内置 工具。dmigrations似乎是这方面的领先工具。

ORM 的另一个选择是SQLAlchemy，它看起来更成熟一些。

于 2009-06-16T18:36:03.070 回答