指导组织大型Django项目 [英] Guide in organizing large Django projects

问题描述

任何人都可以推荐一个良好的指南/教程/文章，其中提供了关于如何组织和分区大型Django项目的提示/指导方针。

我正在寻找建议，当您需要开始对初始唯一文件（models.py，urls.py，views.py）进行分类和工作时有几十个实体。

解决方案

每个应用程序应该很小 - 一个可重复使用的实体加上几个关联表。我们每个应用程序模型有大约5加/减2表。我们的大部分应用程序都小于5个表。模型中有一个零表。

每个应用程序应该被设计为一个可重用的概念。在我们的案例中，每个申请都是整个网站的一块;应用程序可以单独删除和替换。

的确，这是我们的策略。随着我们的需求的扩大和成熟，我们可以相互独立地移除和替换应用程序。

可以让应用程序相互依赖。然而，这种依赖必须局限于模式和形式等明显的事物。此外，应用程序可以依赖于彼此的URL中的名称。因此，您的命名URL必须具有应用程序视图的形式，因此 reverse 函数或 {％url％} 标签可以正确找到它们。

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

最后，比共享的简单模型或表单更复杂的任何东西都不属于任一应用程序，但是需要成为一个单独的共享库，例如，我们使用 XLRD ，但是包含部分它在我们自己的类中，所以它更像是内置的 csv 模块。这个XLRD的包装不是任何一个应用程序的适当部分，它是一个单独的模块，在Django应用程序之外。

Anyone could recommend a good guide/tutorial/article with tips/guidelines in how to organize and partition a large Django project?

I'm looking for advices in what to do when you need to start factorizing the initial unique files (models.py, urls.py, views.py) and working with more than a few dozens of entities.

解决方案

Each "application" should be small -- a single reusable entity plus a few associated tables. We have about 5 plus/minus 2 tables per application model. Most of our half-dozen applications are smaller than 5 tables. One has zero tables in the model.

Each application should be designed to be one reusable concept. In our case, each application is a piece of the overall site; the applications could be removed and replaced separately.

Indeed, that's our strategy. As our requirements expand and mature, we can remove and replace applications independently from each other.

It's okay to have applications depend on each other. However, the dependency has to be limited to the obvious things like "models" and "forms". Also, applications can depend on the names in each other's URL's. Consequently, your named URL's must have a form like "application-view" so the reverse function or the {% url %} tag can find them properly.

Each application should contain it's own batch commands (usually via a formal Command that can be found by the django-admin script.

Finally, anything that's more complex than a simple model or form that's shared probably doesn't belong to either application, but needs to be a separate shared library. For example, we use XLRD, but wrap parts of it in our own class so it's more like the built-in csv module. This wrapper for XLRD isn't a proper part of any one application, to it's a separate module, outside the Django applications.

这篇关于指导组织大型Django项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！