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/

標籤：Python

上一篇：Python操作excel

下一篇：python 基礎知識5-集合