Python 大型Django应用程序布局

我在一个开发基于网络的大学门户的团队中，该门户将基于Django。我们仍处于探索阶段，我正试图找到规划项目/开发环境的最佳方法

我最初的想法是将系统开发为一个Django“app”，其中包含用于分离系统不同部分的子应用程序。我之所以打算创建这些“子”应用程序，是因为它们在父应用程序之外没有任何用途，所以将它们单独分发没有什么意义。我们设想门户将安装在多个位置（例如，在不同的大学），因此可以将主应用程序放入多个Django项目中进行安装。因此，每个位置的项目都有一个不同的存储库，它实际上只是一个定义已安装门户应用程序的

settings.py

文件，以及一个

url.py

将URL路由到它

不过，我已经开始编写一些初始代码，我遇到了一个问题。处理用户身份验证和配置文件的一些代码似乎没有主页。它在概念上不属于门户应用程序，因为它与门户的功能无关。但是，它也不能进入项目存储库，因为我会在每个位置的存储库上复制代码。例如，如果我在这段代码中发现了一个bug，我将不得不手动在该位置的所有项目文件上复制修复

我对修复的想法是将所有的项目回购作为“主”位置项目的一个分支，这样我就可以从该主位置获取任何更改。我认为这很混乱，这意味着我还有一个存储库要处理

---

我正在寻找一个更好的方式来实现这个项目。有谁能推荐一个解决方案或类似的例子让我看看吗？问题似乎是我正在开发一个Django项目，而不仅仅是一个Django应用程序。

您应该看看：

• 德扬戈
• Django最佳实践，如果您想重复使用
• GIT或任何其他CVS（GIT非常适合维护+部署）
• 如果您需要自动化部署/更新

我通常使用此项目结构：

• /Django项目
  • /应用程序
    • /main#主代码
    • /静态#每个子应用程序都可以提供静态服务
    • /附件1
    • /静态#每个子应用程序都可以提供静态服务
    • /附件2
  • /脚本#manage.py、wsgi、apache.conf、fabfile.py
  • /核心#你的图书馆
  • 设置.py
  • 本地_settings.py

/apps中的每个应用程序都有一个URL.py，该URL.py自动包含在主URL.py中。每个应用程序都可以是git子模块（或svn外部）

此外，使用git，您可以处理不同的并行分支（master/dev/customerA/customerB…）和合并更新

---

使用django创建真正可重用的应用程序并不容易。

我发现最好的方法是创建应用程序，然后创建一个项目将它们粘合在一起。我的大多数项目都有类似的应用程序，它们都包含在每个项目中。电子邮件、笔记、动作提醒、用户身份验证等。我的首选布局如下：

• 计划/
  • 设置.py
  • url.py
  • views.py
• 应用程序/
  • 电子邮件/
    • url.py
    • views.py
  • 注释/
    • url.py
    • views.py

应用程序：

每个“应用程序”都独立存在，除了

settings.py

，它们不依赖于项目本身（尽管它可以依赖于其他应用程序）。其中一个应用程序是用户身份验证和管理。它在

apps/auth/URLs.py

中有用于完成任务的所有URL。其所有模板都位于

apps/auth/templates/auth/

中。它的所有功能都是自包含的，所以当我需要调整某些东西时，我知道该去哪里

项目：

项目/

包含将这些单独的应用程序组合到最终项目中所需的所有粘合剂。在我的例子中，我大量使用了

设置。在
project/
中安装了应用程序

，以识别哪些应用程序视图对我可用。这样，如果我从我安装的

应用程序中取出
应用程序.notes
，一切仍然运行得很好，只是没有任何注释

维护：

这种布局/方法/计划也有长期的积极影响。您可以在以后重复使用任何应用程序，几乎不需要任何工作。您可以自下而上测试系统，确保每个应用程序在集成到整个系统之前都能按预期工作，帮助您更快地发现/修复错误。您可以实现一个新功能，而无需将其推出到应用程序的现有实例中（如果它不在
已安装的应用程序中，它们将看不到它）

我确信有更好的文档化方法来规划项目，也有更广泛使用的方法，但这是迄今为止对我最有效的方法。
您可以将常用功能提取到单独的模块中，并使您的应用程序依赖它：


我的门户
认证模块
profiles\u模块
应用程序1（取决于身份验证模块）
应用程序2（取决于身份验证模块和配置文件模块）

我认为，一个“经典”Django项目似乎“包含”了它正在使用的应用程序，这一事实阻止了你看到图片——事实上，这是没有必要的。对于一个项目，您将拥有某种可插入模块，我建议将应用程序组织为鸡蛋，并使用zc.buildout+djangomipe来管理一切

这样，您就可以将模块保持在一个扁平的一级结构中。鸡蛋能够指定依赖项，所以
[buildout]
extends = base_deployment.cfg
eggs += application1

[buildout]
extends = base_seployment.cfg
eggs += application1
        application2