大型Django应用布局

Question

我在一个团队里，正在开发一个基于网页的大学门户网站，使用的是Django框架。我们现在还处于探索阶段，我在想怎么搭建这个项目和开发环境。

我最初的想法是把这个系统做成一个Django的“应用”，里面包含一些子应用，用来把系统的不同部分分开。之所以想这样做，是因为这些“子”应用在主应用之外没有任何用处，所以单独分发它们没有意义。我们设想这个门户网站会在多个地方安装（比如不同的大学），所以主应用可以放到多个Django项目中进行安装。因此，我们为每个地点的项目准备了不同的代码库，实际上这只是一个settings.py文件，用来定义已安装的门户应用，还有一个urls.py文件，用来处理网址的路由。

不过，我已经开始写一些初步的代码，遇到了一个问题。处理用户认证和个人资料的部分代码似乎没有合适的归属。因为这些功能和门户网站的功能没有直接关系，所以它不应该放在门户应用里。但是，它也不能放在项目的代码库里，因为那样的话，我就会在每个地点的代码库里重复这段代码。如果我发现这段代码有bug，比如说，我就得手动在所有地点的项目文件里修复一遍。

我想出的一个解决办法是把所有项目的代码库都作为一个“主”地点项目的分支，这样我就可以从主项目中拉取任何更改。不过我觉得这样有点麻烦，还多了一个代码库需要管理。

我在寻找一个更好的方法来实现这个项目。有没有人能推荐一个解决方案或者类似的例子让我参考一下？问题似乎在于我在开发一个Django 项目，而不仅仅是一个Django 应用。

Answer 1

你可以看看以下内容：

• Django的通用关系
• 如果你想重复使用，可以参考Django的可重用应用的最佳实践
• 使用GIT或其他版本控制系统（GIT在维护和部署方面非常棒）
• 如果你需要自动化部署或更新，可以使用Fabric

我通常使用这样的项目结构：

• /djangoproject
  • /apps
    • /main # 主要代码
    • /static # 每个子应用可以提供静态文件
    • /app1
    • /static # 每个子应用可以提供静态文件
    • /app2...
  • /scripts # 包含manage.py、wsgi、apache.conf、fabfile.py等文件...
  • /core # 你的库文件...
  • settings.py
  • local_settings.py

/apps中的每个应用都有一个urls.py文件，这个文件会自动包含在主urls.py中。每个应用也可以是一个git子模块（或者svn外部链接）

此外，使用git的话，你可以在不同的分支上工作（比如master、dev、customerA、customerB等），然后合并更新。

在Django中创建真正可重用的应用并不容易。

Answer 2

你可以把一些共同的功能提取到一个单独的模块里，然后让你的应用依赖这个模块：

• 我的门户网站
• 认证模块
• 用户资料模块
• 应用程序1（依赖认证模块）
• 应用程序2（依赖认证模块和用户资料模块）

我觉得传统的Django项目看起来“包含”了它所使用的应用，这让你难以看到全貌——其实这并不是必要的。如果你的项目需要一些可插拔的模块，我建议把应用组织成“蛋”（egg），并使用zc.buildout和djangorecipe来管理一切。

这样你就可以把模块保持在一个简单的单层结构中。蛋有能力指定依赖关系，所以如果你安装了应用程序1（如上所示），认证模块会自动安装。

而且，部署到不同服务器时，配置也会很简单。比如，你有一台服务器server1上安装了应用程序1，另一台服务器server2上安装了应用程序1和应用程序2——你只需要两个配置文件：

server1.cfg：

[buildout]
extends = base_deployment.cfg
eggs += application1

server2.cfg：

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

djangorecipe还允许你为每个buildout配置指定不同的设置文件，这样你就可以把必要的部分添加到主项目的URL和已安装应用的设置中。

更不用说，你还可以为开发环境设置一个单独的配置（比如，debug=True并安装Django Debug Toolbar）。

Answer 3

我发现最好的做法是先创建一些应用程序，然后再做一个项目把它们连接在一起。我的大多数项目都有一些相似的应用，比如邮件、笔记、提醒事项、用户认证等等。我喜欢的布局大致是这样的：

• 项目文件夹/
  • settings.py
  • urls.py
  • views.py
  • ...
• 应用文件夹/
  • emails/
    • urls.py
    • views.py
    • ...
  • notes/
    • urls.py
    • views.py
    • ...
  • ...

应用：

每个“应用”都是独立的，除了一个 settings.py 文件外，不依赖于整个项目（不过它可以依赖其他应用）。其中一个应用是用户认证和管理。它所有的任务相关链接都在 apps/auth/urls.py 里。它的所有模板都在 apps/auth/templates/auth/ 里。它的功能都是自包含的，所以当我需要修改某些东西时，我知道该去哪里。

项目：

project/ 文件夹包含了把这些独立应用组合成最终项目所需的所有内容。在我的情况下，我在 project/ 中大量使用了 settings.INSTALLED_APPS 来判断哪些应用的视图可以用。这样，如果我把 apps.notes 从 INSTALLED_APPS 中移除，其他功能仍然可以正常工作，只是没有笔记功能。

维护：

这种布局/方法/计划还有长期的积极影响。你可以在之后几乎不费力地重用任何应用。你可以从底层开始测试系统，确保每个应用都按预期工作，然后再整合到一起，这样可以更快找到和修复bug。你可以实现新功能，而不需要在现有的应用实例中推出（如果它不在 INSTALLED_APPS 中，它们就看不到）。

我相信还有更好、更广泛使用的项目布局方式，但到目前为止，这种方式对我来说是最有效的。