“Django應用、配置文件以及其他各種相關目錄的最佳布局是什么樣的？”

總是有朋友問我們這個問題，因此我想花一點時間，寫一下我們究竟是如何看待這個問題的，這樣我們就可以很容易讓其他人參照這個文檔。請注意，這里是基于 Django 1.7.1 版寫的，但是可以很容易應用在 Django 1.4 版之后任何版本。

雖然 Django 1.4 發(fā)布時，它包含了一個改進后的項目布局（這還用了很長一段時間），但本文有一些優(yōu)化項目布局的更好建議。
為什么這種布局比較好

我們在這里推薦的項目布局有幾個優(yōu)點，即：

1.     讓你獲得、重新打包并復用單個的Django應用來用于其他的項目。這通常是不明確的，正如你正在構(gòu)建一個不管是否要復用的應用。在一開始以想要復用的方式構(gòu)建應用，會讓這一切變得更加簡單。
2.     鼓勵設計可復用的應用。
3.     環(huán)境的詳細設置。在一個單一的整體配置文件中，if DEBUG==True 沒有什么意義。這使得很容易能看到哪些配置是共享的，哪些是在每個環(huán)境的基礎上可覆寫的。
4.     環(huán)境的具體安裝要求(PIP requirements)。
5.     如果有必要，項目級的模板和靜態(tài)文件可以覆寫應用級的默認值。
6.     小而更具體的測試文件更易于閱讀和理解。

假設你有兩個應用 blog 和 users，以及兩個開發(fā)環(huán)境 dev 和 prod。你的項目布局結(jié)構(gòu)應該是這樣的：
 

本文的剩余部分介紹了如何將項目遷移到這個布局，以及為什么這種布局比較好。
當前默認布局

我們將調(diào)用示例項目foo，我知道這是一個非常有創(chuàng)意的名字。我們假設在這里，我們將要啟動foo.com。但當我們希望將我們的項目名稱映射最終域名時，該項目將以不以任何意義要求的方式存在在這里。

如果你使用 django-admin.py startproject foo 命令開啟這個項目，你會得到一個像這樣的目錄結(jié)構(gòu)：
 

foo/
  manage.py
  foo/
    __init__.py
    settings.py
    urls.py
    wsgi.py

這種布局是一個好起點，我們有一個頂級目錄foo，里面包含了manage.py文件和項目目錄foo/foo/。在這個目錄，你可以查詢到源代碼控制系統(tǒng)（比如 Git） 。

你應該想到子目錄foo/foo/就是這個項目。這里的所有文件，不是一個Django應用程序，就是與項目相關的配套文件。
修改配置

這里的任務是修正不好的配置文件。我將這個布局向新用戶展示，我往往驚訝于這幾個人怎么知道這甚至可能做到。事實上，當大家都知道這些配置只是Python代碼時，他們也不將它們當做Python代碼。

因此，讓我們來改進配置。對于oo項目而言，將有4個開發(fā)環(huán)境：dev、stage、jenkins 和 production。給每個開發(fā)環(huán)境一個它們自己的配置文件。這個過程中要做的事情是：

    在foo/foo/目錄下新建一個配置目錄，并在里面創(chuàng)建一個空的__init __.py文件。
    將foo/foo/settings.py移動并重命名為foo/foo/settings/base.py。
    在foo/foo/settings/目錄下創(chuàng)建單獨的dev.py、stage.py、jenkins.py 和 production.py文件。這四種環(huán)境的特定配置文件應該包含如下內(nèi)容：
   

  from base import *

為什么這很重要呢？對于本地開發(fā)你想要設置DEBUG=True，但很容易不小心將這個推到生產(chǎn)代碼中，因此需要打開 foo/foo/settings/production.py 文件，在初始導入base后加上DEBUG=False?，F(xiàn)在，對于這種愚蠢的錯誤，你的生產(chǎn)環(huán)境是安全的。

還有什么可以定制？很明顯你可以針對不同的數(shù)據(jù)庫，甚至是不同的主機來配置staging、jenkins和production等開發(fā)環(huán)境。然后在每個環(huán)境配置文件中來調(diào)整那些配置。
使用這些配置

無論你通常使用哪種方法，使用這些配置都非常簡單。要使用該操作系統(tǒng)的環(huán)境，你只要做：
 

export DJANGO_SETTINGS_MODULE=“foo.settings.jenkins”

現(xiàn)在你就在使用 jenkins 的配置。

或者，也許你更喜歡把它們作為這樣的命令行選項：
 

./manage.py migrate —settings=foo.settings.production

同樣的，如果你使用 gunicorn，命令則如下：
 

gunicorn -w 4 -b 127.0.0.1:8001 —settings=foo.settings.dev

還有什么可自定義的配置？

另一個實用建議是將一些默認的集合配置從元組改為列表。例如 INSTALLED_APPS，將它從：
 

INSTALLED_APPS =（
...
）

改為：
 

INSTALLED_APPS = [
  …
]

現(xiàn)在，基于每個環(huán)境的特定配置文件，我們可以更輕松地在 foo/settings/base.py文件中添加和刪除應用。例如，你可能只想在dev環(huán)境而不是其他環(huán)境中安裝Django調(diào)試工具欄。

這個技巧對 TEMPLATE_DIRS和MIDDLEWARE_CLASSES 配置也非常有用。

我們經(jīng)常使用的另一個技巧是把應用分為兩個列表，一個是項目的必要前提，另一個用于實際項目應用。如下面所示：
 

PREREQ_APPS = [
  ‘django.contrib.auth',
  ‘django.contrib.contenttypes',
  …
  ‘debug_toolbar',
  ‘imagekit',
  ‘haystack',
]
 
PROJECT_APPS = [
  ‘homepage',
  ‘users',
  ‘blog',
]
 
INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS

為什么這個有用？第一，它有助于更好地區(qū)分Django核心應用、第三方應用及你自己的內(nèi)部項目的具體應用。對于測試和代碼覆蓋率等事情，寫明你的特定應用的PROJECT_APPS列表往往就派上了用場。你有寫一個應用列表，因此你可以輕松自動地確保它們的測試運行，記錄的測試覆蓋率只包括它們而不包括任何第三方的應用，且無需在兩個不同的地方維護這個列表。
修改要求

大多是項目有一個requirements.txt文件，它用如下命令安裝：
 

pip install -r requirements.txt

對于簡單的小項目這以足夠了，但requirements.txt文件有一個鮮為人知的特點是，你可以使用-r參數(shù)來包括其他文件。因此，對于所有常見的安裝要求，我們可以創(chuàng)建一個base.txt文件；然后，如果我們需要能夠運行測試，我們可以創(chuàng)建一個包含如下內(nèi)容的特定的requirements/test.txt文件：
 

我承認這沒有巨大的好處，但它確實有助于區(qū)分什么是每個開發(fā)環(huán)境的要求。同時，對于其性能，它不會安裝一堆在實際生產(chǎn)中用不上的東西，來減少生產(chǎn)環(huán)境中的pip安裝時間。
測試文件

我們?yōu)槭裁匆鸱趾艽蟮臏y試文件呢？其中的一個主要原因是，如果你在一個tests.py文件中對每個應用寫了足夠多的測試，那么這個文件最終將變得非常臃腫。這樣的代碼可讀性很差，并且你不得不在編輯器中花很多時間來滾動瀏覽代碼。

當你和其他開發(fā)者一起工作時，小文件也能讓你在代碼合并時少遇到?jīng)_突。小文件是你的朋友。
URLs

對于小型項目，把所有的URL定義放在foo/urls.py文件中，讓它們在同一個地方。但是，如果你的目標是代碼的清晰和可復用，你最好在每個應用中定義它們的url，再將它們包含在你的主項目中。你不應如下所做：
 

urlpatterns = patterns(‘',
  url(r'^$', HomePageView.as_view(), name=‘home'),
  url(r'^blog/$', BlogList.as_view(), name=‘blog_list'),
  url(r'^blog/(?P<pk>d+)/$', BlogDetail.as_view(), name=‘blog_detail'),
  …
  url(r'^user/list/$', UserList.as_view(), name=‘user_list'),
  url(r'^user/(?P<username>w+)/$', UserDetail.as_view(), name=‘user_detail'),
)

你應該這樣做：
 

urlpatterns = patterns(‘',
  url(r'^$', HomePageView.as_view(), name=‘home'),
  url(r'^blog/‘, include(‘blog.urls')),
  url(r'^user/‘, include(‘user.urls')),
)

模板和靜態(tài)資源

每個應用中都有templates/和static/目錄，這讓一個應用可以基本上復用到其他的項目中。

對于一個很酷的功能，我們?nèi)谝粋€包中獲得應用提供的默認模板和任何相關的靜態(tài)資源，如特殊的Javascript。

但是，它也讓我們可以覆寫每個項目主目錄foo/templates/下的模板。我們通過增加一個 templates/blog/detail.html 模板覆寫默認的 blog/templates/blog/detail.html 模板。
復用Django應用

假設你已經(jīng)使用這個布局一段時間，有一天你會意識到你的新項目需要一個blog應用，這個從你的foo項目出來的應用將是完美的。所以你復制、粘貼文件……錯誤！現(xiàn)在你有這個應用的兩個副本。假定你還記得，在一個副本中進行Bug修復和新功能增添需要手動地在項目間遷移。

相反，為你的博客創(chuàng)建一個新的目錄，并把foo/blog/目錄中的內(nèi)容放入其中。同時，調(diào)整現(xiàn)有的foo項目和你的新項目來進行安裝。

如果需要的話，它們?nèi)匀豢梢愿欉@兩個不同版本的應用，或持續(xù)更新，且獲得它們不斷發(fā)展中的所有bug修復和新功能。你仍然可以在每個項目的基礎上，根據(jù)需求覆寫模板和靜態(tài)資源，所以這樣做真的沒有任何問題。

最新評論