我已经用谷歌搜索了这个，但我仍然无法理解 Django 定义为“应用程序”的内容。
我是否应该为站点中的每个功能创建一个新应用程序，即使它使用来自主项目的模型？
你们对何时拆分新应用程序以及何时将功能与“主项目”或其他应用程序保持在一起有很好的经验吗？
Håkan
问问题
34864 次
8 回答
48
James Bennett 有一组精彩的幻灯片，介绍如何在 Django 中组织可重用的应用程序。
于 2008-09-15T16:35:16.020 回答
24
我更喜欢将 Django 应用程序视为可重用的模块或组件，而不是“应用程序”。
这有助于我封装某些功能并将某些功能彼此分离，如果我决定与整个社区共享一个特定的“应用程序”，则可以提高可重用性和可维护性。
我的一般方法是将特定功能或功能集存储到“应用程序”中，就好像我要公开发布它们一样。这里的困难部分是弄清楚每个桶有多大。
我使用的一个好技巧是想象如果我的应用程序公开发布后会被如何使用。这经常鼓励我缩小桶并更清楚地定义其“目的”。
于 2008-09-15T16:32:07.243 回答
19
这是 2008 年 9 月 6 日的更新演示文稿。
取自幻灯片
这应该是它自己的应用程序吗？
- 它与应用程序的焦点完全无关吗？
- 它与我正在做的其他事情正交吗？
- 我需要在其他网站上使用类似的功能吗？
如果其中任何一个是“是”？然后最好将其分解为一个单独的应用程序。
于 2011-11-07T09:15:00.783 回答
14
我倾向于为每个逻辑上独立的模型集创建新的应用程序。例如：
- 用户资料
- 论坛帖子
- 博客文章
于 2008-09-15T16:12:39.147 回答
7
我在网上找到的这个问题的两个最佳答案是：
- 其他答案中也提到了可重用应用程序谈话（幻灯片）（视频）。Bennett，作者和 Django 贡献者，定期发布应用程序供其他人使用，并对许多小型应用程序有强烈的看法。
- Doordash's Tips for Django at Scale给出了相反的建议，并在他们的案例中说，他们在从许多单独的应用程序开始后迁移到了一个应用程序。他们遇到了应用程序之间迁移依赖图的问题。
两个消息来源都同意您应该在以下情况下创建一个单独的应用程序：
- 如果您计划在另一个 Django 项目中重用您的应用程序（特别是如果您计划将其发布以供其他人重用）。
- 如果应用程序与另一个应用程序之间几乎没有或没有依赖关系。在这里，您也许可以想象未来一个应用程序会作为自己的微服务运行。
于 2018-12-12T02:16:39.307 回答
6
我遵循的规则是，如果我想在不同的项目中重用该功能，它应该是一个新应用程序。
如果它需要深入了解项目中的模型，那么将其与模型结合起来可能更具凝聚力。
于 2008-09-16T00:01:11.250 回答
2
Andrew Godwin（Django 核心开发人员）给出了这个问题的最佳答案：
在我看来，应用程序的主要目的是提供可重用组件的逻辑分离——特别是模型/管理员/等的一流命名空间。- 并提供一种简单的方法来“打开”或“关闭”事物。
在某些方面，它是创建 Django 的时代的遗物——当时 Python 打包和模块开发得少得多，你基本上必须有自己的解决方案来解决这个问题。也就是说，它仍然是 Django 心智模型的核心部分，而且我认为 INSTALLED_APPS 仍然是比 Python 的入口点替代产品更清洁、更简单的解决方案（这使得禁用安装在环境中但你不这样做的包非常困难不想使用）。
您认为有什么特别的东西可以与今天的应用程序概念脱钩吗？模型和管理员需要它来进行自动发现和唯一的命名空间前缀，所以这很难撤消，而且我正在努力考虑你需要它的其他功能（事实上，如果你想要的只是一个库，你可以做到一个普通的 Python —— 不需要应用程序包装，除非你发送模型、模板或管理代码 IIRC）
于 2020-10-21T12:33:10.340 回答
1
一个“应用程序”可以是许多不同的东西，这一切都归结为品味。例如，假设您正在构建一个博客。您的应用程序可以是整个博客，或者您可以有一个“管理”应用程序、一个用于所有公共视图的“站点”应用程序、一个“rss”应用程序、一个“服务”应用程序，以便开发人员可以在他们的自己的方式等
我个人会让博客本身成为应用程序，并分解其中的功能。然后可以在其他网站中轻松地重复使用该博客。
Django 的好处是它可以将目录树的任何级别中的任何 models.py 文件识别为包含 Django 模型的文件。因此，将您的功能分解为“应用程序”本身内更小的“子应用程序”不会让任何事情变得更加困难。
于 2008-09-15T22:56:37.600 回答