前言
Django作爲一個龐大的、自帶電池的、整體Web開發解決方案框架，源代碼多、子系統多、工具多。要將如此多的內容集成到一起，必然需要一個指導性的設計理念和哲學思維。這樣纔不至於顯得東拼西湊、雜亂無章、接口混亂，而是整體一致、思路清晰、邏輯合理。既方便了源碼開發，也方便了應用開發。
下面就介紹一下Django的設計理念和哲學思維，這其中有一些是Django源代碼中正在遵循的，一些是使用者開發項目過程中需要遵循的：
系統性原則
松耦合
Django 追求各子系統（層）的低耦合和高內聚。各層之間保持代碼獨立、功能獨立、儘量沒有交聯。
例如，模板層不需要知道用戶的 Web 請求具體情況，模型層不需要了解模板層是如何展示數據的，視圖層也不關心程序員所使用的模板系統到底是哪種和怎麼使用的。通俗地說，模型層只關心數據的CRUD，視圖層只負責業務邏輯的實現，模板層只管前端頁面的渲染和展示。這三個核心層之間只有數據的傳遞，沒有代碼的交互，各自相對獨立。
更少的代碼
Django 建議每個APP的代碼應該儘可能地精簡，應該充分利用 Python 的動態能力，比如自省機制（introspection）。
快速開發
Django誕生於一個新聞編輯社，其應用環境要求快速開發和迅速迭代，所以在設計之初就追求以更快的速度實現需求的處理，你只需要編寫一些新代碼，或者修改一些局部代碼就可以實現新的站點。
不要重複地造輪子 (DRY)
除非有特殊需求，所有官方或者生態圈內已經提供的庫、工具、插件和功能，請直接拿來使用，不要自己開發。
明確優於隱式
這條原則的根本意思是：不要玩花招、炫技巧，儘可能用更普通、更明確、更直觀的語法，不要使用那些晦澀難懂的語法。將你的代碼寫得更囉嗦、更直白、更清晰，多兩行不怕，多點註釋更好。
一致性
框架應在所有層級上保持一致。一致性適用於從低級（Python 的編碼風格）到高級（使用 Django 的“經驗”）的所有內容。
這條規則既有代碼規範上的要求，也有開發習慣的要求，要在整個項目中保持統一的風格。代碼如其人，程序員是個什麼樣的性子和思路，在代碼裏能看得清清楚楚。要保持人設的統一性，不要前面是狂野粗放的大漢，後面是裹腳布又臭又長，這樣不好，讓人以爲代碼是好多不同的人寫的，沒有一個統一的章法。
模型層相關
明確優於隱式
字段不應該僅僅根據字段的名稱來假定某些行爲。這需要對系統有太多瞭解，並且容易出現錯誤。相反，其行爲應該基於關鍵字參數，並且在某些情況下，應該基於字段的類型。
白話說就是：不要通過字段的名稱上來指定它的功能，而應該通過詳細、明確地選擇字段的類型，定義字段的參數來設計字段。
模型應當包含所有信息
模型中應該封裝一個“對象”的各個方面，並遵循 Martin Fowler 的 Active Record 設計模式。
也就是說，對於一個模型，任何與之相關的元信息、方法、函數、屬性，包括其人類可讀的名稱，默認排序等選項，這些所有用於理解該模型所需的信息，都應該存儲在模型中，而不要將它們放到視圖、URL或者模板中去實現。
ORM相關
提高SQL效率
應該儘可能少地執行SQL語句，並且應該在內部優化語句。
開發者需要顯式地調用 save()，而不是由框架靜默地在幕後保存數據。
API應該簡潔並強大
ORM的API 應該允許用盡可能少的語法，來表達豐富、達意的語句。它不應該依賴於導入其他模塊或輔助對象。
每一個對象都應該能夠訪問所有相關的對象，和系統範圍，並且這種訪問應該是雙向的。
支持使用原生 SQL 語句
ORM的API 只是一個便捷的方法，但並不是最終的全部手段，框架必須支持使用原生SQL語句，這一點Django做到了。
URL 設計相關
松耦合
Django 應用中的 URL 不應該與底層 Python 代碼耦合。將 URL 與 Python 函數名聯繫起來是一件很糟糕且醜陋的做法。
也就是說，APP中的視圖到底幹什麼，和你的URL到底寫成啥樣沒有關係，不能將URL和APP捆在一起綁死了。例如，一個網站可以在 /stories/ 中放置故事，而另一個網站則可以使用 /news/來放置故事，兩種不同的URL其背後的APP是一樣的，我雖然複用了APP，但我可以使用另外一套URL去映射它。
無限的靈活性
URL 應該儘可能靈活。任何可想到的 URL 設計都應該被允許。
URL應該優雅
設計漂亮的URL，而不是難看的 URL。
在 URL 中應避免出現文件後綴名。
在 URL 中不應使用 Vignette 式的逗號。
最後的斜槓
從技術上而言，foo.com/bar 和 foo.com/bar/ 是兩條不同的 URL，搜索引擎爬蟲（以及某些 Web 流量分析工具）會將其視爲獨立的兩個頁面。但是Django 會將其轉爲 "標準" 的 URL，讓搜索引擎爬蟲正確識別。詳細參考 APPEND_SLASH 配置。
模板系統相關
邏輯分離的解決方案
我們將模板系統看作一個工具，用於控制表現方式和表示方式相關的邏輯。模板系統不應該支持超出這個基本目標的功能。
避免冗餘
大多數動態網站會使用一些網站整體通用的設計，比如通用的頁眉、頁腳、導航欄等等。Django 模板系統遵循了這一點，可以很容易地將這些元素存儲在一個地方，從而減少重複的代碼。
從 HTML 中解耦
模板系統不應該被設計成只能輸出 HTML。它應該同樣擅長生成其他基於文本的格式，或者僅僅是純文本。
XML不應被用於模板語言
使用 XML 引擎去解析模板會在編輯模板的過程中引入很多人爲錯誤，並在模板處理中導致不可接受的開銷。
不要指望模板系統能包打天下
Django 期望模板編寫者有能力直接編輯 HTML 文本。
更加直接的處理空格
模板系統不應該用空白符來做神奇的事情。如果模板包含空白符，系統應該在處理文本時處理空格——只是顯示它。任何不在模板標籤中的空白符都應該顯示出來。
不要發明一種編程語言
模板系統的目標不是發明一種編程語言。它的目標是提供足夠的具有編程風格的功能，比如分支和循環，這對於做出表現相關的決策是至關重要的。Django 模板語言（DTL） 旨在避免高級邏輯。
Django 模板系統認爲模板通常是由 設計師 編寫的，而不是 程序員，因此不應該假設他了解 Python。
所以，我們在使用Django的模板系統時會發現，這只是一個具有一般編程功能的渲染工具，不要妄圖把它當作一個功能強大、語法完整的編程語言來使用。
安全與保障
開箱即用的模板系統禁止包含惡意代碼，例如刪除數據庫記錄的代碼。
這也是模板系統不允許有任意Python代碼的另一個原因。
可擴展性
模板系統應該認識到, 高階的模板作者可能想擴展它。
這是自定義的模板標籤和過濾器背後的理念。
視圖
儘量簡潔
編寫視圖應該和編寫 Python 函數一樣簡單。開發人員不應該在函數執行時實例化一個類。
使用請求對象
視圖應該能夠訪問一個請求對象——一個儲存關於當前請求的元數據的對象。對象應該直接傳遞給視圖函數，而不是必須從全局變量訪問請求數據的視圖函數。這使得通過傳入“假”請求對象來測試視圖變得輕鬆、乾淨和容易。
根據這條理念，Django每個視圖函數的第一個參數都是request，從這個request中，我們可以拿到所有用戶請求相關的數據。
松耦合
視圖不應該關心開發人員使用哪種模板——甚至根本不用模板系統。
GET 方法和 POST 方法的區別
GET 和 POST 是不同的；開發人員應該明確地使用其中一個或另一個。框架應該使得 GET 和 POST 數據很容易區分。
所以，在使用函數型視圖的時候，應該明確地寫明：if request.method=='GET':pass，而不要使用默認的函數執行順序。
緩存框架相關
緩存框架 的核心目的是：
更少的代碼
緩存應該儘可能快。因此，圍繞緩存後端的所有框架代碼都應該保持在絕對的最小值，特別是對於 get() 操作。
一致性
緩存 API 應該爲不同的緩存後端提供一致的接口。
可擴展性
緩存 API 應該基於開發者的需求，在應用程序級別上是可擴展的
是不是感覺雲裏霧裏的？沒關係，在這裏LZ爲大家推薦一本高效學習Django的PDF文檔，想免費獲取的讀者朋友們，請關注小編，並私信回覆【Django】來免費領取吧！！！
由於篇幅限制，細節無法完全展示，如果有對這本Django實戰資料感興趣的，記得關注小編後私信回覆【Django】哦~~~