Django高階之中介軟體

django 中的中介軟體（middleware），在django中，中介軟體其實就是乙個類，在請求到來和結束後，django會根據自己的規則在合適的時機執行中介軟體中相應的方法。

在django專案的settings模組中，有乙個 middleware_classes 變數，其中每乙個元素就是乙個中介軟體

中介軟體中一共有四個方法：

process_request

process_view

process_exception

process_response

process_request(self,request)

process_response(self, request, response)

當使用者發起請求的時候會依次經過所有的的中介軟體，這個時候的請求時process_request,最後到達views的函式中，views函式處理後，在依次穿過中介軟體，這個時候是process_response,最後返回給請求者

在django中叫中介軟體，在其他web框架中，有的叫管道，httphandle

上述截圖中的中介軟體都是django中的，我們也可以自己定義乙個中介軟體，我們可以自己寫乙個類，但是必須繼承middlewaremixin

所以需要匯入：from django.utils.deprecation import middlewaremixin

我們在專案檔案下建立乙個middle目錄，並在下面建立m1.py**例子如下：

中介軟體1請求")

defprocess_response(self,request,response):

print("

中介軟體1返回")

return

response

class

row2(middlewaremixin):

defprocess_request(self,request):

print("

中介軟體2請求")

#return httpresponse("走")

defprocess_response(self,request,response):

print("

中介軟體2返回")

return

response

class

row3(middlewaremixin):

defprocess_request(self,request):

print("

中介軟體3請求")

defprocess_response(self,request,response):

print("

中介軟體3返回")

return response

這樣當頁面發起請求的時候：後台效果如下

但是如果當請求到達請求2的時候直接不符合條件返回，程式將吧請求直接發給中介軟體2返回，然後依次返回到請求者

用如下圖進行理解：

當然這是在django1.10的時候，在之前的版本的時候是直接返回到最後乙個中介軟體的response,然後向上依次返回，最後到發起請求

process_view(self, request, callback, callback_args, callback_kwargs)

我們在m1.py檔案中的的**進行更改：

中介軟體1請求")

defprocess_response(self,request,response):

print("

中介軟體1返回")

return

response

defprocess_view(self, request, callback, callback_args, callback_kwargs):

print("

中介軟體1view")

class

row2(middlewaremixin):

defprocess_request(self,request):

print("

中介軟體2請求")

#return httpresponse("走")

defprocess_response(self,request,response):

print("

中介軟體2返回")

return

response

defprocess_view(self, request, callback, callback_args, callback_kwargs):

print("

中介軟體2view")

class

row3(middlewaremixin):

defprocess_request(self,request):

print("

中介軟體3請求")

defprocess_response(self,request,response):

print("

中介軟體3返回")

return

response

defprocess_view(self, request, callback, callback_args, callback_kwargs):

print("

中介軟體3view

")高亮部分為新增的內容，這樣執行之後效果如下：

我們通過下圖進行分析上面的過程：

當最後乙個中間的process_request到達路由關係對映之後，返回到中介軟體1的process_view，然後依次往下，到達views函式，最後通過process_response依次返回到達使用者

process_exception(self, request, exception)

當views的函式**現錯誤時，就會執行process_exception方法

如果在中間中新增了process_exception方法，工作圖示為：

這樣當使用者發起請求的時候到達中介軟體3的process_request之後會到達urls路由關係對映這裡，如果匹配到了就會到中介軟體1的process_view,然後依次傳遞到中介軟體3的process_view,到達view函式。如果view函式中有報錯，則會從中介軟體3依次向上判斷每個中介軟體的process_exception是否能匹配到這個錯誤資訊，如果匹配到則直接返回到最後乙個中介軟體，這裡即中介軟體3的process_response，然後依次返回到使用者，如果沒有匹配到這個錯誤則直接在頁面顯示錯誤資訊。如果view函式中沒有錯誤，則到中間3即最後乙個中介軟體3的process_response，然後依次向上，傳到使用者

process_template_response(self,request,response)

只有當views函式中返回的物件中具有render方法，是就會直接process_template_responseprocess

Django高階之中介軟體

Django高階之中介軟體

Django之中介軟體

Django 之中介軟體

Django高階之中介軟體

Django高階之中介軟體

Django之中介軟體

Django 之 中介軟體

相關推薦

Django 之中介軟體