Django设计理念
設計理念
本文檔解釋了 Django 開發(fā)人員在開發(fā) Django 時使用的一些基本哲學， 它的目標是解釋過去并指導未來。
總體
松耦合
Django 棧的基本目標是 低耦合高內(nèi)聚?？蚣芾锏牟煌瑢?#xff08;Layers）不應該知道對方的代碼，除非它們確實需要。
例如，模板系統(tǒng)不需要知道用戶的 Web 請求，數(shù)據(jù)庫層不需要了解如果顯示數(shù)據(jù)，而視圖并不關心程序員所使用的模板系統(tǒng)。
盡管為了方便 Django 帶有一個完整的堆棧，但堆棧的各個部分盡可能獨立于另一個堆棧。
更少的代碼
Django 應用的代碼應該盡可能地精簡，Django 應該充分利用 Python 的動態(tài)能力，比如自省機制（introspection）。
快速開發(fā)
在 21 世紀，Web 框架的核心一點是讓 Web 開發(fā)中枯燥的事情處理得更加快速，Django 可以做到快速的 Web 開發(fā)。
不要重復地造輪子 (DRY)
每個獨特的概念或數(shù)據(jù)片應該存在且只存在于一個地方。避免冗余，做好標準化。
合理的框架應該從盡可能少的信息中推斷出盡可能多的需求。
參見
波特蘭模式知識庫中關于DRY的討論
明確優(yōu)于隱式
這是在 PEP 20 列出的核心 Python 原則，這意味著 Django 不應該使用太多的“魔術”。除非有一個很好的理由，否則不應該出現(xiàn)魔術。只有當魔術創(chuàng)造了巨大的便利，并且使用其他方式難以實現(xiàn)時，它才值得使用，而且它的實現(xiàn)方式并不會讓試圖學習如何使用該功能的開發(fā)人員感到困惑。
一致性
框架應在所有層級上保持一致。一致性適用于從低級（Python 的編碼風格）到高級（使用 Django 的“經(jīng)驗”）的所有內(nèi)容。
模型
明確優(yōu)于隱式
字段不應該僅僅根據(jù)字段的名稱來假定某些行為。這需要對系統(tǒng)有太多了解，并且容易出現(xiàn)錯誤。相反，其行為應該基于關鍵字參數(shù)，并且在某些情況下，應該基于字段的類型。
包括所有相關領域邏輯
模型應該封裝一個“對象”的各個方面，遵循 Martin Fowler 的 Active Record 設計模式。
這就是為什么在模型類中要同時定義一個模型表現(xiàn)的數(shù)據(jù)以及關于它的信息（包括其人類可讀的名稱，默認排序等選項）；所有用于理解給定模型所需的信息都應該存儲在模型中。
數(shù)據(jù)庫API
數(shù)據(jù)庫API的主要用處：
SQL效率
應該盡可能少地執(zhí)行SQL語句，并且應該在內(nèi)部優(yōu)化語句。
這就是為什么開發(fā)者需要顯式地調(diào)用 save()，而不是由框架靜默地在幕后保存東西。
這也是為什么 select_related() QuerySet 方法存在的原因。在查詢“每個關聯(lián)的對象”的常見情況下，它是一個可選的性能提升器。
簡潔, 強大的語法
數(shù)據(jù)庫 API 應該允許用盡可能少的語法，來表達豐富、達意的語句。它不應該依賴于導入其他模塊或輔助對象。
當必要時, 在幕后插入應該是自動進行的。
每一個對象都應該能夠訪問所有相關的對象, 系統(tǒng)范圍. 這種訪問應該是雙向的。
當有必要時, 可方便地選擇使用原始 SQL 語句
應該認識到數(shù)據(jù)庫 API 只是一個便捷的方法，但并不必須是最終的全部手段。框架應該可以很容易地編寫自定義的 SQL——完整的語句，或者僅僅是自定義 WHERE 子句作為 API 調(diào)用時的自定義參數(shù)。
URL 設計
松耦合
Django 應用中的 URL 不應該與底層 Python 代碼耦合。將 URL 與 Python 函數(shù)名聯(lián)系起來是一件很糟糕且丑陋的做法。
按照這些方法，Django URL 系統(tǒng)應該允許同一應用的 URL 在不同的上下文中有所不同。例如，一個網(wǎng)站可以在 /stories/ 中放置故事，而另一個網(wǎng)站則可以使用 /news/。
無限的靈活性
URL 應該盡可能靈活。任何可想到的 URL 設計都應該被允許。
鼓勵最佳實踐
框架可以做到讓開發(fā)者簡單（或更加簡單）地設計出漂亮的，而不是難看的 URL。
在 URL 中應避免出現(xiàn)文件后綴名。
在 URL 中使用 Vignette 式的逗號應該受到嚴厲的懲罰。
定義URL
技術上，foo.com/bar 和 foo.com/bar/ 是兩條不同的 URL，搜索引擎爬蟲（以及某些 Web 流量分析工具）會將其視為獨立的頁面。Django 會將其轉(zhuǎn)為 “標準” 的 URL，讓搜索引擎爬蟲正確識別。
詳細請參考 APPEND_SLASH 配置。
模板系統(tǒng)
邏輯分離的解決方案
我們將模板系統(tǒng)看作一個工具，用于控制表現(xiàn)方式和表示方式相關的邏輯。模板系統(tǒng)不應該支持超出這個基本目標的功能。
避免冗余
大多數(shù)動態(tài)網(wǎng)站會使用一些網(wǎng)站整體通用的設計——一個通用的頁眉、頁腳、導航欄，等等。Django 模板系統(tǒng)應該可以很容易地將這些元素存儲在一個地方，從而減少重復的代碼。
這是 模板繼承 背后的理念。
從 HTML 中解耦
模板系統(tǒng)不應該被設計成只能輸出 HTML。它應該同樣擅長生成其他基于文本的格式，或者僅僅是純文本。
XML不應被用于模板語言
使用 XML 引擎去解析模板會在編輯模板的過程中引入很多人為錯誤，并在模板處理中導致不可接受的開銷。
承擔設計能力
模板系統(tǒng)不應該有的設計是，使得模板可以在WYSIWYG（所見即所得）編輯器中也能顯示得很好，比如 Dreamweaver。因為這是一個非常嚴重的限制，會讓模板的語法不夠好。Django 期望模板編寫者有能力直接編輯 HTML 文本。
更加直接的處理空格
模板系統(tǒng)不應該用空白符來做神奇的事情。如果模板包含空白符，系統(tǒng)應該在處理文本時處理空格——只是顯示它。任何不在模板標簽中的空白符都應該顯示出來。
不要發(fā)明一種編程語言
模板系統(tǒng)的目標不是發(fā)明一種編程語言。它的目標是提供足夠的具有編程風格的功能，比如分支和循環(huán)，這對于做出表現(xiàn)相關的決策是至關重要的。Django 模板語言（DTL） 旨在避免高級邏輯。
Django 模板系統(tǒng)認為模板通常是由 設計師 編寫的，而不是 程序員，因此不應該假設他了解 Python。
安全與保障
開箱即用的模板系統(tǒng)禁止包含惡意代碼，例如刪除數(shù)據(jù)庫記錄的代碼。
這就是模板系統(tǒng)不允許有任意Python代碼的另一個原因。
可擴展性
模板系統(tǒng)應該認識到, 高階的模板作者可能想擴展它。
這是自定義的模板標簽和過濾器背后的理念。
視圖
簡潔
編寫視圖應該和編寫 Python 函數(shù)一樣簡單。開發(fā)人員不應該在函數(shù)執(zhí)行時實例化一個類。
使用請求對象
視圖應該能夠訪問一個請求對象——一個儲存關于當前請求的元數(shù)據(jù)的對象。對象應該直接傳遞給視圖函數(shù)，而不是必須從全局變量訪問請求數(shù)據(jù)的視圖函數(shù)。這使得通過傳入“假”請求對象來測試視圖變得輕松、干凈和容易。
松耦合
視圖不應該關心開發(fā)人員使用哪種模板——甚至根本不用模板系統(tǒng)。
GET 方法和 POST 方法的區(qū)別
GET 和 POST 是不同的；開發(fā)人員應該明確地使用其中一個或另一個?？蚣軕撌沟?GET 和 POST 數(shù)據(jù)很容易區(qū)分。
緩存框架
緩存框架 的核心目的是：
更少的代碼
緩存應該盡可能快。因此，圍繞緩存后端的所有框架代碼都應該保持在絕對的最小值，特別是對于 get() 操作。
一致性
緩存 API 應該為不同的緩存后端提供一致的接口。
可擴展性
緩存 API 應該基于開發(fā)者的需求，在應用程序級別上是可擴展的（例如，參見 緩存鍵轉(zhuǎn)換）。
總結(jié)
以上是生活随笔為你收集整理的Django设计理念的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Django 模型 —— 字段类型
- 下一篇： Linux（树莓派）安装 python-