設(shè)計(jì)理念

本文檔解釋了 Django 開(kāi)發(fā)人員在開(kāi)發(fā) Django 時(shí)使用的一些基本哲學(xué)， 它的目標(biāo)是解釋過(guò)去并指導(dǎo)未來(lái)。

總體

松耦合

Django 棧的基本目標(biāo)是 低耦合高內(nèi)聚。框架里的不同層（Layers）不應(yīng)該知道對(duì)方的代碼，除非它們確實(shí)需要。

例如，模板系統(tǒng)不需要知道用戶的 Web 請(qǐng)求，數(shù)據(jù)庫(kù)層不需要了解如果顯示數(shù)據(jù)，而視圖并不關(guān)心程序員所使用的模板系統(tǒng)。

盡管為了方便 Django 帶有一個(gè)完整的堆棧，但堆棧的各個(gè)部分盡可能獨(dú)立于另一個(gè)堆棧。

更少的代碼

Django 應(yīng)用的代碼應(yīng)該盡可能地精簡(jiǎn)，Django 應(yīng)該充分利用 Python 的動(dòng)態(tài)能力，比如自省機(jī)制（introspection）。

快速開(kāi)發(fā)

在 21 世紀(jì)，Web 框架的核心一點(diǎn)是讓 Web 開(kāi)發(fā)中枯燥的事情處理得更加快速，Django 可以做到快速的 Web 開(kāi)發(fā)。

不要重復(fù)地造輪子 (DRY)

每個(gè)獨(dú)特的概念或數(shù)據(jù)片應(yīng)該存在且只存在于一個(gè)地方。避免冗余，做好標(biāo)準(zhǔn)化。

合理的框架應(yīng)該從盡可能少的信息中推斷出盡可能多的需求。

參見(jiàn)
波特蘭模式知識(shí)庫(kù)中關(guān)于DRY的討論

明確優(yōu)于隱式

這是在 PEP 20 列出的核心 Python 原則，這意味著 Django 不應(yīng)該使用太多的“魔術(shù)”。除非有一個(gè)很好的理由，否則不應(yīng)該出現(xiàn)魔術(shù)。只有當(dāng)魔術(shù)創(chuàng)造了巨大的便利，并且使用其他方式難以實(shí)現(xiàn)時(shí)，它才值得使用，而且它的實(shí)現(xiàn)方式并不會(huì)讓試圖學(xué)習(xí)如何使用該功能的開(kāi)發(fā)人員感到困惑。

一致性

框架應(yīng)在所有層級(jí)上保持一致。一致性適用于從低級(jí)（Python 的編碼風(fēng)格）到高級(jí)（使用 Django 的“經(jīng)驗(yàn)”）的所有內(nèi)容。

模型

明確優(yōu)于隱式

字段不應(yīng)該僅僅根據(jù)字段的名稱來(lái)假定某些行為。這需要對(duì)系統(tǒng)有太多了解，并且容易出現(xiàn)錯(cuò)誤。相反，其行為應(yīng)該基于關(guān)鍵字參數(shù)，并且在某些情況下，應(yīng)該基于字段的類型。

包括所有相關(guān)領(lǐng)域邏輯

模型應(yīng)該封裝一個(gè)“對(duì)象”的各個(gè)方面，遵循 Martin Fowler 的 Active Record 設(shè)計(jì)模式。

這就是為什么在模型類中要同時(shí)定義一個(gè)模型表現(xiàn)的數(shù)據(jù)以及關(guān)于它的信息（包括其人類可讀的名稱，默認(rèn)排序等選項(xiàng)）；所有用于理解給定模型所需的信息都應(yīng)該存儲(chǔ)在模型中。

數(shù)據(jù)庫(kù)API

數(shù)據(jù)庫(kù)API的主要用處：

SQL效率

應(yīng)該盡可能少地執(zhí)行SQL語(yǔ)句，并且應(yīng)該在內(nèi)部?jī)?yōu)化語(yǔ)句。

這就是為什么開(kāi)發(fā)者需要顯式地調(diào)用 save()，而不是由框架靜默地在幕后保存東西。

這也是為什么 select_related() QuerySet 方法存在的原因。在查詢“每個(gè)關(guān)聯(lián)的對(duì)象”的常見(jiàn)情況下，它是一個(gè)可選的性能提升器。

簡(jiǎn)潔, 強(qiáng)大的語(yǔ)法

數(shù)據(jù)庫(kù) API 應(yīng)該允許用盡可能少的語(yǔ)法，來(lái)表達(dá)豐富、達(dá)意的語(yǔ)句。它不應(yīng)該依賴于導(dǎo)入其他模塊或輔助對(duì)象。

當(dāng)必要時(shí), 在幕后插入應(yīng)該是自動(dòng)進(jìn)行的。

每一個(gè)對(duì)象都應(yīng)該能夠訪問(wèn)所有相關(guān)的對(duì)象, 系統(tǒng)范圍. 這種訪問(wèn)應(yīng)該是雙向的。

當(dāng)有必要時(shí), 可方便地選擇使用原始 SQL 語(yǔ)句

應(yīng)該認(rèn)識(shí)到數(shù)據(jù)庫(kù) API 只是一個(gè)便捷的方法，但并不必須是最終的全部手段。框架應(yīng)該可以很容易地編寫自定義的 SQL——完整的語(yǔ)句，或者僅僅是自定義 WHERE 子句作為 API 調(diào)用時(shí)的自定義參數(shù)。

URL 設(shè)計(jì)

松耦合

Django 應(yīng)用中的 URL 不應(yīng)該與底層 Python 代碼耦合。將 URL 與 Python 函數(shù)名聯(lián)系起來(lái)是一件很糟糕且丑陋的做法。

按照這些方法，Django URL 系統(tǒng)應(yīng)該允許同一應(yīng)用的 URL 在不同的上下文中有所不同。例如，一個(gè)網(wǎng)站可以在 /stories/ 中放置故事，而另一個(gè)網(wǎng)站則可以使用 /news/。

無(wú)限的靈活性

URL 應(yīng)該盡可能靈活。任何可想到的 URL 設(shè)計(jì)都應(yīng)該被允許。

鼓勵(lì)最佳實(shí)踐

框架可以做到讓開(kāi)發(fā)者簡(jiǎn)單（或更加簡(jiǎn)單）地設(shè)計(jì)出漂亮的，而不是難看的 URL。

在 URL 中應(yīng)避免出現(xiàn)文件后綴名。

在 URL 中使用 Vignette 式的逗號(hào)應(yīng)該受到嚴(yán)厲的懲罰。

定義URL

技術(shù)上，foo.com/bar 和 foo.com/bar/ 是兩條不同的 URL，搜索引擎爬蟲（以及某些 Web 流量分析工具）會(huì)將其視為獨(dú)立的頁(yè)面。Django 會(huì)將其轉(zhuǎn)為 “標(biāo)準(zhǔn)” 的 URL，讓搜索引擎爬蟲正確識(shí)別。

詳細(xì)請(qǐng)參考 APPEND_SLASH 配置。

模板系統(tǒng)

邏輯分離的解決方案

我們將模板系統(tǒng)看作一個(gè)工具，用于控制表現(xiàn)方式和表示方式相關(guān)的邏輯。模板系統(tǒng)不應(yīng)該支持超出這個(gè)基本目標(biāo)的功能。

避免冗余

大多數(shù)動(dòng)態(tài)網(wǎng)站會(huì)使用一些網(wǎng)站整體通用的設(shè)計(jì)——一個(gè)通用的頁(yè)眉、頁(yè)腳、導(dǎo)航欄，等等。Django 模板系統(tǒng)應(yīng)該可以很容易地將這些元素存儲(chǔ)在一個(gè)地方，從而減少重復(fù)的代碼。

這是 模板繼承 背后的理念。

從 HTML 中解耦

模板系統(tǒng)不應(yīng)該被設(shè)計(jì)成只能輸出 HTML。它應(yīng)該同樣擅長(zhǎng)生成其他基于文本的格式，或者僅僅是純文本。

XML不應(yīng)被用于模板語(yǔ)言

使用 XML 引擎去解析模板會(huì)在編輯模板的過(guò)程中引入很多人為錯(cuò)誤，并在模板處理中導(dǎo)致不可接受的開(kāi)銷。

承擔(dān)設(shè)計(jì)能力

模板系統(tǒng)不應(yīng)該有的設(shè)計(jì)是，使得模板可以在WYSIWYG（所見(jiàn)即所得）編輯器中也能顯示得很好，比如 Dreamweaver。因?yàn)檫@是一個(gè)非常嚴(yán)重的限制，會(huì)讓模板的語(yǔ)法不夠好。Django 期望模板編寫者有能力直接編輯 HTML 文本。

更加直接的處理空格

模板系統(tǒng)不應(yīng)該用空白符來(lái)做神奇的事情。如果模板包含空白符，系統(tǒng)應(yīng)該在處理文本時(shí)處理空格——只是顯示它。任何不在模板標(biāo)簽中的空白符都應(yīng)該顯示出來(lái)。

不要發(fā)明一種編程語(yǔ)言

模板系統(tǒng)的目標(biāo)不是發(fā)明一種編程語(yǔ)言。它的目標(biāo)是提供足夠的具有編程風(fēng)格的功能，比如分支和循環(huán)，這對(duì)于做出表現(xiàn)相關(guān)的決策是至關(guān)重要的。Django 模板語(yǔ)言（DTL） 旨在避免高級(jí)邏輯。

Django 模板系統(tǒng)認(rèn)為模板通常是由 設(shè)計(jì)師 編寫的，而不是 程序員，因此不應(yīng)該假設(shè)他了解 Python。

安全與保障

開(kāi)箱即用的模板系統(tǒng)禁止包含惡意代碼，例如刪除數(shù)據(jù)庫(kù)記錄的代碼。

這就是模板系統(tǒng)不允許有任意Python代碼的另一個(gè)原因。

可擴(kuò)展性

模板系統(tǒng)應(yīng)該認(rèn)識(shí)到, 高階的模板作者可能想擴(kuò)展它。

這是自定義的模板標(biāo)簽和過(guò)濾器背后的理念。

視圖

簡(jiǎn)潔

編寫視圖應(yīng)該和編寫 Python 函數(shù)一樣簡(jiǎn)單。開(kāi)發(fā)人員不應(yīng)該在函數(shù)執(zhí)行時(shí)實(shí)例化一個(gè)類。

使用請(qǐng)求對(duì)象

視圖應(yīng)該能夠訪問(wèn)一個(gè)請(qǐng)求對(duì)象——一個(gè)儲(chǔ)存關(guān)于當(dāng)前請(qǐng)求的元數(shù)據(jù)的對(duì)象。對(duì)象應(yīng)該直接傳遞給視圖函數(shù)，而不是必須從全局變量訪問(wèn)請(qǐng)求數(shù)據(jù)的視圖函數(shù)。這使得通過(guò)傳入“假”請(qǐng)求對(duì)象來(lái)測(cè)試視圖變得輕松、干凈和容易。

松耦合

視圖不應(yīng)該關(guān)心開(kāi)發(fā)人員使用哪種模板——甚至根本不用模板系統(tǒng)。

GET 方法和 POST 方法的區(qū)別

GET 和 POST 是不同的；開(kāi)發(fā)人員應(yīng)該明確地使用其中一個(gè)或另一個(gè)。框架應(yīng)該使得 GET 和 POST 數(shù)據(jù)很容易區(qū)分。

緩存框架

緩存框架 的核心目的是：

更少的代碼

緩存應(yīng)該盡可能快。因此，圍繞緩存后端的所有框架代碼都應(yīng)該保持在絕對(duì)的最小值，特別是對(duì)于 get() 操作。

一致性

緩存 API 應(yīng)該為不同的緩存后端提供一致的接口。

可擴(kuò)展性

緩存 API 應(yīng)該基于開(kāi)發(fā)者的需求，在應(yīng)用程序級(jí)別上是可擴(kuò)展的（例如，參見(jiàn) 緩存鍵轉(zhuǎn)換）。

總結(jié)

以上是生活随笔為你收集整理的Django设计理念的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。