logo标签列表

Django： "projects"与"apps"的区别

pythondjangonamespacesproject-organization
221

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

项目可以有多个应用程序。应用程序可以在多个项目之间共享。很好。

我不会重新发明博客或论坛 - 我不认为我的产品中的任何部分可在任何情况下重复使用。直觉上，我会称之为“应用程序”。那么所有工作都在一个“app”文件夹中完成吗？

如果是这样... 根据Django的project.app命名空间，我倾向于使用myproduct.myproduct，但是这当然是不允许的（但我正在构建的应用程序是我的项目，我的项目是一个应用程序！）。因此，我认为也许我应该通过每个“重要”模型构建一个应用程序来处理Django，但我不知道在我的模式中如何划分边界以将其分成应用程序 - 我有许多模型具有相对复杂的关系。

我希望有一个常见的解决方案...

1
文档在这里解释了“应用程序”和“项目”的区别：https://docs.djangoproject.com/en/dev/ref/applications/#projects-and-applications - guettli
6个回答
104

一旦您完成使用startproject和startapp，就可以将"项目"和"应用程序"组合到同一个Python包中。 项目实际上只是一个settings模块，而应用程序实际上只是一个models模块 - 其他所有内容都是可选的。

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

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py
21
简述：项目有settings.py，应用程序有models.py。它们具有相同的层次结构。我曾经以为项目比应用程序高一级，看来我错了。 - Philip007
2
@claymation，在设置（作为应用程序）中应包括什么，以便允许“python manage.py makemigrations”或“python manage.py migrate”查看“my product”目录中的“models.py”文件？ - mlwn
1
@mlwn，我知道我的回答已经超级晚了，但我自己也处于类似的情况，并查看了很多答案。为了回答你的问题，你只需要将你的项目包含在“INSTALLED_APPS”列表中即可。这里是一个例子：https://stackoverflow.com/a/59739912/399435 - Karthic Raghupathi
@KarthicRaghupathi，谢谢.. :) 很高兴看到四年后的评论得到回复.. 干杯 - mlwn
72
尝试回答这个问题：“我的应用程序是做什么的？” 如果您无法用一句话回答，那么也许您可以将其拆分为具有更清晰逻辑的几个应用程序。
我在开始使用Django后不久就在某个地方读到了这个想法，并且我经常问自己这个问题，这对我很有帮助。
您的应用程序不必是可重用的，它们可以相互依赖，但它们应该只做一件事。
9
当涉及到设计自己的应用程序时，我仍然感到有些困难。我觉得我的主要应用程序有点过于复杂，但同时，我无法将其重构为类似于松散耦合的东西。如果我的主要实体仍然彼此密切依赖，并且没有重用或泛化的需求，那么将它们分开可能并不会有所改善。因此，我倾向于认为“不要过早地重构”是“不要过早进行优化”的一种解释。 - acjay
59

有什么阻止你使用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的默认设置不会这样做。
  • 通常，我想创建一个主应用程序，因此我会创建一个通常称为网站的应用程序。但是，在以后的某个日期，我可能希望开发专门针对此站点的原始功能。考虑到将其移除（无论是否如此），我倾向于随后创建一个单独的目录。这也意味着我可以通过取消链接配置文件中的该软件包并删除文件夹来放弃该功能，而不是从全局urls.py文件中删除正确的URL。
  • 即使我想要使某些东西独立，很常见的问题是，当我看护它/使它独立时，它需要一个地方居住。基本上是上述情况，但适用于我打算普遍使用的东西。
  • 我的顶级文件夹经常包含一些其他东西，包括但不限于wsgi脚本、sql脚本等。
  • Django的管理扩展依赖于子目录。因此，适当命名包是有意义的。
简而言之，存在这种约定的原因与其他约定相同——它有助于他人处理您的项目。如果我看到fields.py，我立即期望其中的代码是django字段的子类，而如果我看到inputtypes.py，我可能不太清楚它的含义，除非我查看它。
26
“有什么阻止你使用我的产品.myproduct吗？” - Django的“startapp”命令实际上会阻止你这样做，我认为这是一种惯例。在团队合作的背景下，我喜欢遵循惯例，但我更愿意理解它们背后的逻辑 :) - Dolph
@Dolph 啊，是吗？自从第一次使用它以来，我就没有再用过它，因为我有自己的命令来创建项目，首先创建模型，然后自动生成这些模型的CRUD内容。不过，确实，约定是好的。我遵循 Django 的约定，只是因为它们大体上讲是有道理的。 - user257111
1
我要补充一点，如果在项目中同时使用相同的名称来命名项目和应用程序，这也会导致manage.py出现问题，从而无法正确导入项目设置。我曾经遇到过这种情况，解决方法是将应用程序重构为myproduct_app。 - BHSPitMonkey
16
8
如果按照Django项目的app命名空间，我倾向于使用myproduct.myproduct，但这当然是不被允许的。
没有什么是不被允许的。这是你的项目，没有人会限制你。建议使用合理的名称。
我没有看到我的产品的任何部分在任何情况下都可以重复使用。直觉上，我会称其为“应用程序”。那么我是否需要在单个“app”文件夹中完成所有工作呢？
在一般的Django项目中有许多应用程序（contrib应用程序）实际上在每个项目中都使用。假设您的项目只执行一个任务，并且只有一个应用程序（我将其命名为main，因为该项目围绕它展开，几乎不可插入）。即使这个项目通常也会使用其他应用程序。
现在，如果您说您的项目仅使用一个应用程序（INSTALLED_APPS='myproduct'），那么定义项目为project.app的用途是什么？我认为您应该考虑一些要点：
- 除了应用程序之外，代码中还有许多其他事情需要处理（基本静态文件，基本模板，设置...即提供基础）。 - 在一般的project.app方法中，Django会自动从模型定义SQL模式。 - 使用传统方法构建您的项目会更容易。 - 您可能希望为URL、视图和其他文件定义一些不同的名称，但我认为这并不需要。 - 您可能需要在未来添加一些应用程序，这在传统的Django项目中非常容易，否则可能变得同样或更加困难和繁琐。
至于大部分工作都在应用程序中完成，我认为这是大多数Django项目的情况。
1
+1，特别是对于像这样的原始项目，main约定非常有意义。我确实计划稍后添加“可重用”的应用程序，但现在这远远超出了我的关注重点。 - Dolph
2

Django 创造者指出了他们自己的不同之处。

我认为将应用程序视为可以在其他项目中可重复使用的是好的做法。在 Django 中思考应用程序的方式也提供了现代 Web 应用程序的好方法。

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

您可以在 Django 中创建一个名为“FrontEnd”的 App，其中您将显示内容。

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

通过这种方式，您始终可以重复使用“Comments”App。您可以将其作为开源发布，而无需公开整个项目的源代码。同时，保持项目的逻辑清晰。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接