django源碼設計模式

⑴ python中，django框架模式有什麼

Django發布於2005年，是當前Python世界裡最負盛名且成熟的網路框架，最初用來製作在線新聞的Web站點。

Django是一個用Python編寫的開放源代碼的Web應用框架，採用了MVC的框架模式，也有很多人把它稱為MVT模式。

優點：

功能完善且要素齊全：自帶大量常用的工具和框架，適合快速開發企業級網站;

完善的文檔：經過十多年的發展和完善，Django有廣泛的實踐案例和完善的在線文檔，開發者遇到問題可以搜索在線文檔尋求解決方案;

強大的資料庫訪問組件：Django的Model層自帶資料庫ORM組件，使得開發者無需學習SQL語言即可對資料庫進行操作;

先進的APP設計理念：APP是可插拔的，是不可多得的思想，不需要了可以直接刪除，對系統整體影響不大;

自帶台管理系統admin：只需要通過簡單幾行配置和代碼就可以實現一個完整的後台數據管理控制平台。

缺點：

大包大攬：對比flask框架來講，Django不夠輕便，包括的功能太多了;

過度封裝：很多類和方法都封裝了，直接使用比較簡單，改動比較困難;

性能劣勢：Django性能偏低;

模板問題：Django的模板實現了代碼和樣式完全分離，不允許模板里出現Python代碼，靈活度對某些程序員來說可能不夠。

⑵ 什麼是django

Django是一個開放源代碼的Web應用框架，由Python寫成。

⑶ 如何用django開發一個簡易個人Blog-Python

1.網站首頁展示已發布的博客記錄，包括名稱、摘要信息、發布日期、閱讀量及評論數。

2.首頁文章列表可按照分類篩選。

3.點擊標題或閱讀全文鏈接，進入博客閱讀頁面，展示文章標題、內容及評論內容。

博客後台管理部分：（後台套用了一個叫做ACE的後台模板，改造成了django形式的）

1.管理員登錄功能

2.分頁展示文章列表，可查看、編輯、刪除選中文章，並支持批量刪除功能。

3.增加新文章功能，利用網路ueEditor富文本編輯器，支持代碼高亮顯示功能。

4.支持分類的增、刪、改、查功能。

下面是幾張截圖：

首頁文章顯示：

開發環境及軟體版本：

開發是在windows 7,利用sublime text2編輯器。

採用python2.7.3+django1.7.0+mysql

前端採用bootstrap和一些成熟的jquery插件。

開發過程：

1.創建項目及app,規劃項目結構。

2.設計數據模型，即資料庫表及表結構。

3.設計公共展示部分樣式，及後台數據與模板視圖的展示。

4.改造ACE後台模板，添加文章管理、類別管理功能及登錄驗證功能。

5.部署到CentOS6.5，部署方式：nginx+uwsgi+django1.6+mysql

⑷ Django源碼閱讀 (一) 項目的生成與啟動

誠實的說，直到目前為止，我並不欣賞django。在我的認知它並不是多麼精巧的設計。只是由功能堆積起來的"成熟方案"。但每一樣東西的崛起都是時代的選擇。無論你多麼不喜歡，但它被需要。希望有一天，python能有更多更豐富的成熟方案，且不再被詬病性能和可維護性。（屁話結束）
取其精華去其糟粕，django的優點是方便，我們這次源碼閱讀的目的是探究其方便的本質。計劃上本次源碼閱讀不會精細到每一處，而是大體以功能為單位進行解讀。

django-admin startproject HelloWorld 即可生成django項目，命令行是exe格式的。

manage.py 把參數交給命令行解析。

execute_from_command_line() 通過命令行參數，創建一個管理類。然後運行他的 execute() 。

如果設置了reload，將會在啟動前先 check_errors 。

check_errors() 是個閉包，所以上文結尾是 (django.setup)() 。

直接看最後一句 settings.INSTALLED_APPS 。從settings中抓取app
注意，這個settings還不是我們項目中的settings.py。而是一個對象，位於 djangoconf\__init__.py

這是個Settings類的懶載入封裝類，直到 __getattr__ 取值時才開始初始化。然後從Settings類的實例中取值。且會講該值賦值到自己的 __dict__ 上（下次會直接在自己身上找到，因為 __getattr__ 優先順序較低）

為了方便debug，我們直接寫個run.py。不用命令行的方式。
項目下建個run.py，模擬runserver命令

debug抓一下setting_mole

回到 setup() 中的最後一句 apps.populate(settings.INSTALLED_APPS)
開始看 apps.populate()

首先看這段

這些App最後都會封裝成為AppConfig。且會裝載到 self.app_configs 字典中

隨後，分別調用每個appConfig的 import_models() 和 ready() 方法。
App的裝載部分大體如此

為了方便debug我們改寫下最後一句

res的類型是 Command <django.contrib.staticfiles.management.commands.runserver.Command object at 0x00000101ED5163A0>
重點是第二句，讓我們跳到 run_from_argv() 方法，這里對參數進行了若干處理。

用pycharm點這里的handle會進入基類的方法，無法得到正確的走向。實際上子類Commond重寫了這個方法。

這里分為兩種情況，如果是reload重載時，會直接執行 inner_run() ，而項目啟動需要先執行其他邏輯。

django 項目啟動時，實際上會啟動兩次，如果我們在項目入口(manage.py)中設置個print，會發現它會列印兩次。

第一次啟動時， DJANGO_AUTORELOAD_ENV 為None，無法進入啟動邏輯。會進入 restart_with_reloader() 。

在這里會將 DJANGO_AUTORELOAD_ENV 置為True，隨後重啟。

第二次時，可以進入啟動邏輯了。

這里創建了一個django主線程，將 inner_run() 傳入。
隨後本線程通過 reloader.run(django_main_thread) ，創建一個輪詢守護進程。

我們接下來看django的主線程 inner_run() 。

當我們看到wsgi時，django負責的啟動邏輯，就此結束了。接下來的工作交由wsgi伺服器了
這相當於我們之前在fastapi中說到的，將fastapi的app交由asgi伺服器。(asgi也是django提出來的，兩者本質同源)

那麼這個wsgi是從哪來的？讓我們來稍微回溯下

這個settings是一個對象，在之前的操作中已經從 settings.py 配置文件中獲得了自身的屬性。所以我們只需要去 settings.py 配置文件中尋找。

我們來尋找這個 get_wsgi_application() 。

它會再次調用 setup() ，重要的是，返回一個 WSGIHandler 類的實例。

這就是wsgiapp本身。

load_middleware() 為構建中間件堆棧，這也是wsgiapp獲取setting信息的唯一途徑。導入settings.py，生成中間件堆棧。
如果看過我之前那篇fastapi源碼的，應該對中間件堆棧不陌生。
app入口→中間件堆棧→路由→路由節點→endpoint
所以，wsgiapp就此構建完畢，伺服器傳入請求至app入口，即可經過中間件到達路由進行分發。