Django的設計理念和哲學

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 應該基於開發者的需求，在應用程序級別上是可擴展的（例如，參見 Cache key transformation）。

更多內容請訪問: https://www.liujiangblog.com

更多視頻教程請訪問: https://www.liujiangblog.com/video/