Django：“项目”与“应用”

我有一个相当复杂的“产品”，准备使用Django构建。在这种情况下，我将避免使用术语“项目”和“应用程序”，因为我不清楚它们在Django中的具体含义。

项目可以有许多应用程序。应用程序可以在许多项目之间共享。精细。

我不是在改造博客或论坛-我看不到产品的任何部分在任何情况下都可以重用。凭直觉，我将其称为“应用程序”。然后，我是否将所有工作都放在一个“ app”文件夹中？

如果是的话 ...就Django的project.app命名空间而言，我倾向于使用myproduct.myproduct，但这当然是不允许的（但是我正在构建的应用程序是我的项目，而我的项目是一个应用程序！）。因此，我相信我可能应该通过为每个“重要”模型构建一个应用程序来接近Django，但是我不知道在架构中将边界划分为应用程序的位置-我有很多东西具有相对复杂关系的模型。

我希望对此有一个通用的解决方案...

什么是阻止您使用的myproduct.myproduct？要实现该目标，大致需要执行以下操作：

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

等等。如果我说views.py不必打来电话会有所帮助views.py吗？如果您可以在python路径上命名一个将被处理的函数（通常为package.package.views.function_name）。就那么简单。所有这些“项目” /“应用”东西都只是python包。

现在，你应该怎么做？或更确切地说，我该怎么做？好吧，如果你创建一个显著一块可重复使用的功能，好比说一个标记编辑器中，当你创建一个“顶级应用程序”那可能含有widgets.py，fields.py，context_processors.py等等-你可能要导入所有的东西。

同样，如果您可以创建类似博客这样的东西，并且其格式在安装过程中非常通用，则可以将其包装在应用程序中，包括其自己的模板，静态内容文件夹等，并配置Django项目的实例以使用该模板应用程序的内容。

没有硬性规定可以执行此操作，但这是框架的目标之一。包括模板在内的所有内容均允许您从某个通用基础上进行包含，这意味着您的博客应该仅通过照顾自己的一部分就可以紧密地适合任何其他设置。

但是，要解决您的实际问题，是的，没有什么说不能使用顶层项目文件夹的。这就是应用程序要做的，如果您确实愿意，您可以这样做。但是，由于以下几个原因，我倾向于不这样做：

• Django的默认设置不执行此操作。
• 通常，我想创建一个主应用程序，因此我创建了一个通常称为的应用程序website。但是，以后我可能只想为此站点开发原始功能。为了使它可移动（无论我是否曾经做过），我倾向于然后创建一个单独的目录。这也意味着我可以仅通过从配置中取消该程序包的链接并删除文件夹来删除所述功能，而不是从全局urls.py文件夹中删除正确的url。
• 很多时候，即使我想独立做某事，当我照顾它/使其独立时，它也需要一个居住的地方。基本上是上述情况，但对于某些东西，我确实打算将其设为通用。
• 我的顶级文件夹通常包含其他一些内容，包括但不限于wsgi脚本，sql脚本等。
• django的管理扩展依赖于子目录。因此，合理地命名软件包是有意义的。

简而言之，约定的原因与其他约定相同-当涉及到与您的项目一起工作的其他人时，这很有用。如果我看到fields.py我立即希望其中的代码可以将django的字段作为子类，而如果我看到inputtypes.py我可能不那么清楚就不知道这意味着什么。

一旦您从使用startproject和毕业startapp，就不会阻止您在同一Python软件包中组合“项目”和“应用”。项目实际上只不过是一个settings模块，而应用程序实际上只不过是一个models模块，其他所有都是可选的。

对于小型网站，拥有类似以下内容是完全合理的：

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

尝试回答问题：“我的应用程序做什么？”。如果您无法用一个句子回答，那么您可以将其拆分为具有更清晰逻辑的多个应用程序。

在开始与django合作后不久，我在某个地方读了这个想法，发现我经常问自己这个问题，对我有帮助。

您的应用程序不必可重用，它们可以相互依赖，但它们应该做一件事。

我发现以下博客文章对Django应用程序和项目非常有用：

• http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
• http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

原则上，使用django可以自由地组织产品的源代码。

如果是的话...就Django的project.app命名空间而言，我倾向于使用myproduct.myproduct，但当然不允许这样做

没有什么不允许的。它是您的项目，没有人限制您。建议保留一个合理的名称。

我看不到产品的任何部分在任何情况下都可以重用。凭直觉，我将其称为“应用程序”。然后，我是否将所有工作都放在一个“ app”文件夹中？

在一般的django项目中，有很多应用程序（contrib应用程序）在每个项目中都真正使用。

让我们说您的项目仅执行一项任务，并且只有一个应用程序（我将其命名为 main为该项目围绕它展开并且几乎不可插入）。该项目通常也仍然使用其他一些应用程序。

现在，如果您说您的项目仅使用一个应用程序（INSTALLED_APPS='myproduct'），那么project将项目定义为的用途是什么project.app，我认为您应该考虑以下几点：

• 除项目中的应用程序外，代码还可以处理许多其他事情（基本静态文件，基本模板，设置...即提供基本信息）。
• 在一般的project.app方法中，django自动从模型定义sql模式。
• 使用常规方法可以更轻松地构建您的项目。
• 您可以根据需要为url，视图和其他文件定义一些不同的名称，但我认为没有必要。
• 您将来可能需要添加一些应用程序，而这些应用程序对于常规的django项目而言确实很容易，否则可能会变得同等或更困难，乏味。

就应用程序中完成的大多数工作而言，我认为大多数Django项目就是这种情况。

在这里Django的创建者自己指出了这种差异。我认为，考虑必须在其他项目中重复使用的 Apps 是很好的。考虑Django中的Apps也是一种提供现代Web应用程序的好方法。

想象一下，您正在基于JavaScript创建大型动态 Web应用程序。

然后，您可以在django应用程序中创建一个名为“ FrontEnd” <-的应用程序，然后在Thins应用程序中显示内容。

然后，您创建一些后端应用程序。例如，名为“ Comments”的应用程序将存储用户评论。而且“评论”应用程序本身不会显示任何内容。它只是动态 JS 网站的 AJAX请求的API 。

这样，您随时可以重复使用“评论”应用。您可以将其开源，而无需打开整个项目的源码。这样您就可以保持项目的逻辑清晰。