原文地址： Django 1.11.18.dev20181205205104 documentation
設(shè)計哲學
這個文檔闡釋了一些django開發(fā)者使用在django中的基本哲學。它的目標是解釋過去和指導未來怀大。
松耦合
django技術(shù)棧的一個基本目標就是”松耦合、高內(nèi)聚“〈缥澹框架的各個層在不必要的情況下现柠，不必知道其他各層脱惰。
例如抱怔，template層不知道web requests蛀柴，數(shù)據(jù)庫層不知道數(shù)據(jù)展示層螃概，視圖層不在意用戶使用哪個template。
雖然django帶來了全棧解決方案的便捷鸽疾，棧的各個層都盡量獨立于其他的層吊洼。
更少的代碼
django的應(yīng)用應(yīng)該使用盡可能少的代碼，他們那應(yīng)該是缺少樣板制肮。
Django應(yīng)該充分使用python的動態(tài)能力冒窍，比如自省。
快速開發(fā)
21世紀框架的特點是讓冗長復(fù)雜的開發(fā)變得快捷豺鼻。django允許快速進行web開發(fā)综液。
DRY，不要重復(fù)造輪子
每個截然不同的概念或者數(shù)據(jù)應(yīng)該存放在一個地方儒飒，而且只有這個地方谬莹。
冗余是不好的，標準化是好的桩了。
作為框架附帽，合理的情形就是從盡可能少的內(nèi)容推斷出盡可能多的內(nèi)容。
顯示比隱式更好
這是在PEP20中列出的核心python原則井誉，這意味著django不應(yīng)該做太多”魔法方法“蕉扮。至少有一些很耗的理由說明”魔法方法“不應(yīng)該出現(xiàn)。如果”魔法方法“創(chuàng)造了一大堆方便的送悔，并且其他方法難以實現(xiàn)的方法時慢显，這才是”魔法方法“唯一值得使用的地方，并且它不能用一種讓嘗試學歷如何使用這些特性的開發(fā)者感到困惑的方式欠啤。
一致性
框架應(yīng)該從所有層面進行考慮荚藻。這些考慮包括任何事情，從低級的python代碼風格到高級的使用django的經(jīng)驗洁段。
Models
顯示比隱式更好
字段不應(yīng)該假定僅僅由它的名字來確定应狱，這需要太多操作系統(tǒng)的知識并且容易出錯。相反祠丝，在某些情況下疾呻，行為應(yīng)該基于關(guān)鍵字參數(shù)，比如字段的類型写半。
包含所有的相關(guān)域的邏輯
模型應(yīng)該將一個”對象“的所有屬性封裝起來岸蜗，遵循Martin Fowler的Active Record設(shè)計模式。
這就是為什么數(shù)據(jù)用模型來表示叠蝇，并且它被定義在模型類中(比如人類可讀的名字璃岳，默認排序這樣的選項，等等)。所有的信息需要知道被存儲在某一個模型中铃慷。
Database API
以下是database API的核心目標：
高效SQL
應(yīng)該以盡可能少的時間來執(zhí)行SQL单芜，并且應(yīng)該在內(nèi)部優(yōu)化SQL的聲明。
這就是為什么開發(fā)者需要顯示的調(diào)用save()犁柜，而不是框架在場景背后默默的進行保存操作洲鸠。
這也是為什么select_related()方法存在的原因。這是一種非強制執(zhí)行的馋缅，一般情況下選擇所有相關(guān)對象的助推器扒腕。
簡潔又強大的語法
數(shù)據(jù)庫API應(yīng)該允許豐富，在盡可能簡短的語句中富有表現(xiàn)力股囊。不應(yīng)該依賴導入其他模塊或者輔助對象袜匿。
聯(lián)結(jié)應(yīng)該在必要的時候，在使用場景背后被自動執(zhí)行稚疹。
系統(tǒng)層面居灯，每個對象可以被關(guān)聯(lián)對象訪問。
選擇原生SQL更簡單内狗，如果我們需要的話
數(shù)據(jù)庫API應(yīng)該意識到它只是捷徑怪嫌，并非必須×常框架應(yīng)該讓自定義SQL更容易--完整的聲明岩灭，或僅僅通過調(diào)用API自定義WHERE從句。
URL 設(shè)計
松耦合
django應(yīng)用中的路由不應(yīng)該耦合到python代碼上赂鲤。將路由綁定到python函數(shù)名是一種不好而且丑陋的做法噪径。
沿著這些做法，django路由系統(tǒng)允許相同的應(yīng)用在不同的上下文中不同数初。例如找爱，一個站點把要存儲的內(nèi)容放在 /stories/ 中，又或者存放在 /news/中泡孩。
無限的靈活性
路由應(yīng)該盡可能的靈活车摄，任何能想象到的路由設(shè)計都應(yīng)如此。
鼓勵最佳實踐
框架應(yīng)該讓它對開發(fā)者而言變得簡單來設(shè)計漂亮的路由仑鸥。
網(wǎng)頁中的文件的擴展名應(yīng)該被隱藏吮播。
不可更改的路由
從技術(shù)上講，foo.com/bar 和 foo.com/bar/ 是兩個不同的路由眼俊，并且搜索引擎(和其他web分析工具)會把它們當做兩個不同的頁面意狠。django努力的標準化路由，目的是讓搜索引擎不再困惑疮胖。
這就是APPEND_SLASH設(shè)置背后的推論摄职。
模板系統(tǒng)
分離邏輯
我們把模板系統(tǒng)看做一個工具誊役，一個控制頁面展示和頁面展示相關(guān)邏輯的工具。
模板系統(tǒng)不應(yīng)該支持超過它基本目標的功能谷市。
阻止冗余
大多數(shù)動態(tài)網(wǎng)站使用一些常見的網(wǎng)站設(shè)計--通用的header，footer击孩，navigation bar迫悠，等等檬某。django模板系統(tǒng)應(yīng)該讓這些元素存儲在同一個地方更簡單全蝶，從而去除重復(fù)的代碼。
這就是template inheritance背后的設(shè)計哲學肋僧。
從HTML中解耦
模板系統(tǒng)不應(yīng)該設(shè)計為僅僅展示HTML括蝠。它應(yīng)該在生成基于文字的格式化方面同樣優(yōu)秀鞠抑，或者僅僅是文字。
XML不應(yīng)該用于模板語言
在編輯末班時忌警，使用XML引擎來解析模板引入了一個全新的錯誤--并且引發(fā)了一個在模板處理中不可接受的開銷搁拙。
假定設(shè)計者的能力
模板系統(tǒng)不應(yīng)該被設(shè)計，目的是模板必須被很好的展示在所見即所得的編輯器中法绵，比如Dreamweaver箕速。這是嚴重的
