关于python：何时在Django中创建新应用(使用startapp)？

我已经为此进行了搜索，但是在Django定义为" apps"方面仍然存在麻烦。

我是否应该为站点中的每个功能创建一个新应用，即使该应用使用了主项目中的模型？

你们对何时拆分新应用以及何时将功能与"主项目"或其他应用保持在一起有很好的经验吗？

---

James Bennett提供了一组精彩的幻灯片，介绍了如何在Django中组织可重用应用程序。

---

我更喜欢将Django应用程序视为可重用的模块或组件，而不是"应用程序"。

这有助于我封装某些功能并将它们相互分离，从而提高了可重用性(如果我决定与整个社区共享特定的"应用")以及可维护性。

我的一般做法是将特定功能或功能集存储到"应用程序"中，就像我要公开发布它们一样。这里最困难的部分是弄清楚每个存储桶有多大。

我使用的一个好技巧是想象如果我的应用程序公开发布后将如何使用它们。这通常鼓励我缩水缩水，更清楚地定义其"目的"。

---

这是2008年9月6日更新后的演示文稿。

DjangoCon 2008：可重复使用的应用程序@ 7：53

幻灯片：Reusable_apps.pdf

Taken from the slide

Should this be its own application?

• Is it completely unrelated to the appa€?s focus?
• Is it orthogonal to whatever else Ia€?m doing?
• Will I need similar functionality on other sites?

If any of them is"Yes"? Then best to break it into a
separate application.

---

我倾向于为每个逻辑上分离的模型集创建新的应用程序。例如：

• 用户资料
• 论坛帖子
• 博客文章

---

我要遵循的规则是，如果我想在其他项目中重用该功能，则它应该是一个新应用。

如果需要深入了解项目中的模型，则将其与模型结合在一起可能会更有凝聚力。

---

我在网络上找到的对该问题的两个最佳答案是：

其他答案中也提到了可重复使用的应用程序对话(幻灯片)(视频)。 Bennett是Django的作者和撰稿人，他定期发布供他人使用的应用程序，并对许多小型应用程序有强烈的看法。

Doordash的Scale for Django技巧给出了相反的建议，并表示在从许多单独的应用程序开始后，他们迁移到了一个应用程序。他们在应用之间的迁移依赖关系图中遇到了问题。

两个消息来源都同意您在以下情况下创建单独的应用程序：

• 如果您打算在另一个Django项目中重用您的应用程序(尤其是如果您打算将其发布以供其他人重用)。
• 该应用程序与另一个应用程序之间的依赖项很少或没有。在这里，您可能可以想象一个应用程序将来会作为其自己的微服务运行。

---

这个问题的最佳答案是由Andrew Godwin(Django核心开发人员)给出的：

在我看来，应用程序的主要目的是提供可重用组件的逻辑隔离-具体来说，是用于model / admin / etc的一流名称空间。 -并提供一种简单的方法来解决问题或" offa"？。

从某些方面来说，这是创建Django时的遗物-Python封装和模块的开发远不如此，您基本上必须有自己的解决方案。也就是说，它仍然是Djangoa心理模型的核心部分，我认为INSTALLED_APPS仍比Pythona替代入口点提供的方法更干净，更轻松(这使得禁用一个已安装在您不想使用的环境中。

您今天是否特别认为可以与应用程序概念脱钩？模型和管理员需要它来进行自动发现和唯一的名称空间前缀，因此很难撤消，而且我在努力考虑需要它的其他功能时(实际上，如果您想要的只是一个库，您可以将其设为普通的Python版本-无需包装应用程序，除非您要运送模型，模板或管理代码IIRC)

---

一个"应用程序"可能有很多不同的东西，这一切真的让人难以置信。例如，假设您正在构建博客。您的应用程序可以是整个博客，也可以有一个"管理员"应用程序，一个用于所有公共视图的"站点"应用程序，一个" rss"应用程序，一个"服务"应用程序，以便开发人员可以在其博客中与该博客进行交互自己的方式等。

我个人将使博客本身成为应用程序，并扩展其中的功能。然后可以很轻松地在其他网站中重用该博客。

关于Django的一件好事是，它将目录树中任何级别的所有models.py文件都识别为包含Django模型的文件。因此，将功能分解为"应用程序"本身中较小的"子应用程序"并不会增加任何难度。

---