组织大型Django项目的指南

Question

32

有人可以推荐一份好的指南/教程/文章，其中包含组织和划分大型Django项目的技巧和指导吗？

当您需要开始将最初的唯一文件（models.py、urls.py、views.py）进行因式分解并处理超过几十个实体时，我正在寻求建议。

- Sam

2个回答

10

我发现查看大型开源的Django项目并注意该项目的实现方式很有帮助。Django官网上有一份不错的开源项目列表：

Google也有一些类似的资源（尽管其中大部分是较小的插件模板标签和中间件）：

当然，仅仅因为一个项目采用了某种方式，并不意味着那种方式就是正确的方式（或错误的方式）。其中一些项目比其他项目更成功。

最终，真正了解哪种方法行之有效、哪种方法无效的唯一方式就是自己亲自尝试。世界上所有的技巧和提示都不会在你自己尝试之前有所帮助，但它们可以帮助你走向正确的方向。

- Tyson

同意……从参与 Pinax 和 Satchmo 的开发中得到的经验是非常宝贵的。 - Jiaaro

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- S.Lott · Accepted Answer

每个“应用程序”应该很小——一个可重复使用的单一实体再加上几个关联表。我们每个应用模型大约有5左右的表格（误差范围为2）。大多数我们的半打应用小于5个表格，其中一个模型中没有表格。

每个应用程序都应该被设计成一个可重复使用的概念。在我们的情况下，每个应用程序是整个站点的一部分；这些应用程序可以单独移除和替换。

实际上，这是我们的策略。随着我们的需求不断扩展和成熟，我们可以单独地移除和替换应用程序。

应用程序之间可以相互依赖。但是，依赖关系必须限制在显而易见的事物上，比如“模型”和“表单”。此外，应用程序可以依赖于彼此URL中的名称。因此，你命名的URL必须采用形式为“应用程序-视图”的形式，这样reverse函数或者{% url %}标签就能正确找到它们。

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

最后，任何比简单模型或表格更复杂的共享内容可能都不属于任何一个应用程序，而需要成为一个单独的共享库。例如，我们使用XLRD，但是将其部分封装在我们自己的类中，以使它更像内置的csv模块。这个XLRD的包装器不属于任何一个应用程序的正确部分，所以它是一个单独的模块，位于Django应用程序之外。