我需要您的建议来选择一个适用于开发大型项目的Python Web框架：
数据库(Postgresql)将至少有500个表格，其中大多数都具有复合主键、大量约束、索引和查询。起始时会有大约1500个视图。该项目属于金融领域，总是有新的需求。
ORM是否有帮助？
7个回答
12
Django已被许多大型组织（如《华盛顿邮报》等）使用，并且可以很容易地连接Postgresql。我经常使用它，没有遇到任何问题。
- Dan Lorenc
2
Django似乎是一个值得考虑的合理选择。+1 - Brandon E Taylor
1大多数的500个表都有一个复合主键 - Django已经支持了吗？ - harto
8
是的。ORM对于将SQL映射到对象非常重要。
你有三个选择：
使用别人的ORM。
自己开发。
尝试执行低级别的SQL查询，并从结果集中挑选出所需的字段。这实际上是一种ORM，但映射分散在应用程序中。它可能执行速度很快，看起来容易开发，但维护起来却是噩梦。
如果你先设计表格，任何ORM都会很痛苦。例如，“复合主键”通常不是一个好主意，而且使用ORM时几乎总是不明智的。你需要有一个替代的主键。然后你可以拥有所有的复合键和索引。只是它们不会是“主键”。
如果你先设计对象，然后再制定实现对象的表格，ORM将会很愉快、简单并且运行速度快。
- S.Lott
5
由于您的大多数表都具有复合主键，因此您需要一个支持该功能的ORM。 Django的默认ORM不支持复合主键。 SQLAlchemy具有该支持功能（http://www.sqlalchemy.org/features.html）。
TurboGears框架使用SQLAlchemy作为其默认ORM。 Pylons也可以让您使用SQLAlchemy。
还有一些方法可以让Django使用SQLAlchemy，但我自己没有尝试过。 我更喜欢使用Django，但考虑到您的需求，我建议您选择Pylons或TurboGears，而不是将不同的ORM强行添加到系统中。
TurboGears框架使用SQLAlchemy作为其默认ORM。 Pylons也可以让您使用SQLAlchemy。
还有一些方法可以让Django使用SQLAlchemy，但我自己没有尝试过。 我更喜欢使用Django，但考虑到您的需求，我建议您选择Pylons或TurboGears，而不是将不同的ORM强行添加到系统中。
- Joe Brandt
1
1好的建议。另一种选择是修复表设计，使其具有适当的单一代理键，除了应用程序正在使用的任何组合“主”键。 - S.Lott
3
对于包含500个表和1500个视图的可怕数据层复杂性，与大多数答案不同，我个人更喜欢使用SQL（PostgreSQL提供了一个非常优秀的实现，特别是在新的8.4版本中，如果你有机会的话，你应该真的为此进行游说）；唯一我会[勉强]接受的ORM是SQLAlchemy（我不介意的少数ORB之一--但主要的附加值是可移植性到不同的DBMS：如果你致力于只有一个，并且在这种DB复杂性的项目中，你最好是这样的，那么我的个人意见是任何ORM都是多余的，因为数据访问层开发人员将需要对特定的DBMS有深入的了解才能朝着可接受的性能前进）。
选择“原始psycopg2”或SQLAlchemy作为我的数据访问层技术后，这将排除Django（在我的经验中，它只适用于自己的ORM--但这并不适合如此复杂的DB项目，依我之见）。我个人会选择Werkzeug，因为它是最适合需要极高灵活性和强大功能的高度复杂项目的框架--尽管Pylons和Turbogears 2也可以作为备选方案，如果团队没有Web应用程序的经验和技能，那么在Werkzeug这样的灵活框架中创造真正美妙的音乐需要很大努力。
最后但并非最不重要的是，我强烈游说在客户端的呈现层上使用Dojo--一个丰富且结构良好的Javascript框架，为“本地数据”、主机访问等优化了每个浏览器（以及插件如Gears）可以提供的最佳功能，以及先进的UI功能，似乎最有可能减轻后端团队的沉重开发负担（事实上，我强烈建议在服务器端提供基本上RESTful的接口，并将所有呈现工作委托给客户端上的Dojo--请参见此网站获取更多信息，除了我会考虑JSON而不是XML作为首选的交换格式）。但是，我必须承认，我对UI方面的了解远远不如对后端、业务逻辑和整体架构，所以请根据自己的情况权衡。
选择“原始psycopg2”或SQLAlchemy作为我的数据访问层技术后，这将排除Django（在我的经验中，它只适用于自己的ORM--但这并不适合如此复杂的DB项目，依我之见）。我个人会选择Werkzeug，因为它是最适合需要极高灵活性和强大功能的高度复杂项目的框架--尽管Pylons和Turbogears 2也可以作为备选方案，如果团队没有Web应用程序的经验和技能，那么在Werkzeug这样的灵活框架中创造真正美妙的音乐需要很大努力。
最后但并非最不重要的是，我强烈游说在客户端的呈现层上使用Dojo--一个丰富且结构良好的Javascript框架，为“本地数据”、主机访问等优化了每个浏览器（以及插件如Gears）可以提供的最佳功能，以及先进的UI功能，似乎最有可能减轻后端团队的沉重开发负担（事实上，我强烈建议在服务器端提供基本上RESTful的接口，并将所有呈现工作委托给客户端上的Dojo--请参见此网站获取更多信息，除了我会考虑JSON而不是XML作为首选的交换格式）。但是，我必须承认，我对UI方面的了解远远不如对后端、业务逻辑和整体架构，所以请根据自己的情况权衡。
- Alex Martelli
2
根据您想要做的事情，您实际上有几个可能的框架：
[Django] 大而强壮（达到了Python框架的极限），并且是竞赛中最老的。被全球一些“大型”网站使用（[Django sites]）。对于几乎所有内容来说都有点过度，编码方法已经过时。
[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或类似的东西）似乎更加合适。
[Django] 大而强壮（达到了Python框架的极限），并且是竞赛中最老的。被全球一些“大型”网站使用（[Django sites]）。对于几乎所有内容来说都有点过度，编码方法已经过时。
[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或类似的东西）似乎更加合适。
- Pierre Gayvallet
1
我绝对推荐使用Repoze.bfg和SQLAlchemy来实现你所描述的功能。我已经在Django、TurboGears 1、TurboGears 2、Pylons以及纯Zope3中完成了多个项目，并且也尝试过其中的一些。BFG是最适合应对项目在开始时无法预料到的增长方式的框架，但它比Grok或Zope 3更轻量级和简化。此外，它的文档是所有框架中最好的技术文档，虽然不是最容易理解的，但是能够最好地回答你将要遇到的难题。目前我正在做一个类似的项目，我们正在将一堆旧数据库改造成一个新的Web交付应用程序，我们正在使用BFG、一些Pylons、Zope 3适配器、Genshi进行模板处理、SQLAlchemy和Dojo作为前端。我们对BFG非常满意，它的表现非常出色。BFG的类视图实际上是zope多适配器，非常适合只覆盖某些特定领域资源的特定部分。而且完全没有任何魔法全局变量，使得测试和打包变得非常容易，这是我们使用任何框架中最容易的部分。
你的情况可能会有所不同！
你的情况可能会有所不同！
- Iain Duncan - XORNOT Studios
1
我相信你可以用Grok做同样的事情，但我发现BFG的极简主义更适合这种情况。 - Iain Duncan - XORNOT Studios
0
新的需求总是不断出现。
因此，您真正需要的是一个框架，使您能够快速适应不断变化的规格。
从个人经验来看，我只能讨论 Django，因为它可以让您快速上手。
如果您坚持使用其 ORM，那么连接模型将变得非常容易且有用。 您需要熟悉数据库迁移工具，因为 Django 没有内置的工具。 dmigrations 似乎是这方面的领先工具。
另一个 ORM 的选择是 SQLAlchemy，它似乎在开箱即用时更成熟。
从个人经验来看，我只能讨论 Django，因为它可以让您快速上手。
如果您坚持使用其 ORM，那么连接模型将变得非常容易且有用。 您需要熟悉数据库迁移工具，因为 Django 没有内置的工具。 dmigrations 似乎是这方面的领先工具。
另一个 ORM 的选择是 SQLAlchemy，它似乎在开箱即用时更成熟。
- SingleNegationElimination
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接