教育行業(yè)A股IPO第一股（股票代碼 003032）

全國咨詢/投訴熱線：400-618-4000

Django框架中各部分的開發(fā)理念是怎樣的？

更新時間:2022年12月19日17時27分 來源:傳智教育 瀏覽次數(shù):

開發(fā)理念不僅是Django開發(fā)者開發(fā)Django之初的指導思想，也是Django發(fā)展和完善之時應遵循的準則。Django的使用者在使用Django框架時不應與Django開發(fā)者的理念相悖。了解Django開發(fā)理念有助于理解Django框架。下面將介紹Django的開發(fā)理念。

總體上，Django遵循各部分松耦合、代碼盡可能精簡、保證Web開發(fā)效率、避免重復、明確優(yōu)于隱式(保證不熟悉框架的人也能了解框架的工作，或能快速掌握框架的工作)這些理念，同時官方對Django的模型、數(shù)據(jù)庫API、URL設計、模板、視圖以及緩存框架這些部分的設計理念做了進一步細化，具體分別如下：

1.模型

①明確優(yōu)于隱式。模型不應僅基于字段名來假設某些行為，模型的行為應基于關鍵字參數(shù)和字段類型。

②定義模型表現(xiàn)的數(shù)據(jù)以及與數(shù)據(jù)相關的所有信息。模型應按照Martin Fowler(馬丁·福勒）的Active Record(活動記錄)設計模型，一個模型類對應關系數(shù)據(jù)庫中的一個表，一個模型類的實例對應表中的一行記錄。

2.數(shù)據(jù)庫API

①保證效率。應盡量少地執(zhí)行SQL語句、在內(nèi)部優(yōu)化SQL語句。

②簡潔、強大的語法。數(shù)據(jù)庫API語法應以盡可能少的語法，實現(xiàn)豐富且準確的語義。

③提供方便執(zhí)行原始SQL語句的方式。應認識到數(shù)據(jù)庫API只是一個便捷方式，而非最終的全部手段。Django框架應具備容易編寫自定義SQL語句的功能。

3.URL設計

①松耦合。Django應用中的URL不應與底層Python代碼耦合。

②無限靈活。網(wǎng)址應盡可能靈活，任何可想到的URL地址都應被允許。

③鼓勵最佳實踐。Django框架應使開發(fā)人員足夠容易地設計出漂亮的URLs。

④對URL進行定義。技術上，foo.com/bar和foo.com/bar/是兩條不同的URL，搜索引擎與爬蟲會將其視為獨立的頁面，Django會將其轉(zhuǎn)為“標準”的URL，讓搜索引擎與爬蟲正確識別。

4.模板系統(tǒng)

①邏輯與表現(xiàn)分離。模板系統(tǒng)的基本目標是控制表現(xiàn)方式和表現(xiàn)方式邏輯，它不應支持超出基本目標的功能。

②避免冗余。大多數(shù)動態(tài)網(wǎng)站會使用一些網(wǎng)站整體通用的設計，如頁眉、頁腳、導航欄等。Django模板系統(tǒng)應可以很容易地存儲這些元素，從而減少代碼的重復。

③與HTML解耦。模板系統(tǒng)不應被設計成只能輸出HTML，它應該同樣擅長生成純文本，或其他基于文本的格式。

④XML不應被用于模板語言。如果使用XML去解析模板，在編輯模板的過程中會引入很多人為錯誤，在模板處理中導致不可接受的開銷。

⑤預設設計師的能力。Django模板系統(tǒng)不承擔保證模板可以在編輯器中友好顯示的功能，它期望模板編寫者有直接編輯HTML文本的能力。

⑥顯式對待空格。模板系統(tǒng)不應該支持空格實現(xiàn)更多的功能。如果模板包含空格，那么系統(tǒng)在處理文本時只需直接地顯示空格。

⑦不要發(fā)明一種編程語言。模板系統(tǒng)的目標是提供足夠的、具有編程風格的功能，比如分支和循環(huán)，而不是發(fā)明一種編程語言；同時模板語言應避免高級邏輯。

⑧安全和保障。拆箱即用的模板系統(tǒng)應禁止包含惡意代碼，如刪除數(shù)據(jù)庫記錄的命令。這也是模板系統(tǒng)不允許有Python代碼的另一個原因。

⑨可擴展。模板系統(tǒng)應意識到高階的模板作者可能想擴展其技術。

5.視圖

①簡潔。編寫視圖應和編寫Python函數(shù)一樣簡單，開發(fā)人員不應該在函數(shù)執(zhí)行時實例化一個類。

②使用請求對象。視圖應該能夠訪問一個請求對象——一個存儲關于當前請求的元數(shù)據(jù)的對象。對象應該直接傳遞給視圖函數(shù)，而不必從全局變量訪問請求數(shù)據(jù)的視圖函數(shù)。

③松耦合。視圖不應該關心開發(fā)人員使用哪種模板——甚至不關心開發(fā)人員是否使用模板系統(tǒng)。

④GET和POST的區(qū)別?？蚣軕沟肎ET和POST數(shù)據(jù)很容易區(qū)分。

6.緩存框架

①更少的代碼。緩存應該盡可能快，因此，圍繞緩存的所有后端框架代碼都應該保持在絕對的最小值，特別是對于getO操作。

②一致性。緩存API應該為不同的緩存后端提供一致的接口。

③可擴展性。緩存API應該基于開發(fā)者的需求，在應用程序級別上是可擴展的。


0 分享到：
和我們在線交談！