组织大型Django项目的指南

时间:2009-02-09 20:58:23

标签: python django projects

任何人都可以推荐一本好的指南/教程/文章,其中包含如何组织和分区大型Django项目的提示/指南?

我正在寻找建议,当您需要开始分解初始唯一文件(models.py,urls.py,views.py)并与多个实体合作时,该怎么做。

2 个答案:

答案 0 :(得分:38)

每个“应用程序”应该很小 - 一个可重用的实体加上一些相关的表。每个应用程序模型我们有大约5加/减2个表。我们的六个应用程序中的大多数都小于5个表。一个模型中有零表。

每个应用程序都应设计为一个可重用的概念。在我们的例子中,每个应用程序都是整个站点的一部分;申请可以单独删除和更换。

确实,这是我们的策略。随着我们的要求不断扩展和成熟,我们可以相互独立地删除和替换应用程序。

让应用程序相互依赖是可以的。但是,依赖性必须限于“模型”和“形式”等显而易见的事物。此外,应用程序可以依赖于彼此URL中的名称。因此,您的命名网址必须具有“应用视图”之类的表单,以便reverse函数或{% url %}标记可以正确找到它们。

每个应用程序都应该包含它自己的批处理命令(通常通过django-admin脚本可以找到的正式命令。

最后,任何比共享的简单模型或表单更复杂的东西可能不属于任何一个应用程序,但需要是一个单独的共享库。例如,我们使用XLRD,但将它的一部分包装在我们自己的类中,因此它更像是内置的csv模块。 XLRD的这个包装器不是任何一个应用程序的正确部分,它是Django应用程序之外的一个单独的模块。

答案 1 :(得分:10)

我发现查看大型开源Django项目并注意该项目是如何实现的有所帮助。 Django的网站有很多开源项目:

http://code.djangoproject.com/wiki/DjangoResources#Open-SourceDjangoprojects

Google也是如此(尽管其中大多数都是较小的附加模板标签和中间件:

http://code.google.com/hosting/search?q=label:django

当然,仅仅因为一个项目以一种方式做到并不意味着这种方式是正确的方式(或错误的方式)。其中一些项目比其他项目更成功。

最后,真正了解哪些有效且无效的唯一方法就是自己尝试一下。除非你自己试一试,否则世界上所有的提示和提示都无济于事,但它们可以帮助你开始朝着正确的方向前进。