python middleware_Django组件之Middleware

一、中间件

在django的settings.py文件下，有一个变量为middleware，里面放的就是中间件。

middleware = [

‘django.middleware.security.securitymiddleware’,

‘django.contrib.sessions.middleware.sessionmiddleware’,

‘django.middleware.common.commonmiddleware’,

‘django.middleware.csrf.csrfviewmiddleware’,

‘django.contrib.auth.middleware.authenticationmiddleware’,

‘django.contrib.messages.middleware.messagemiddleware’,

‘django.middleware.clickjacking.xframeoptionsmiddleware’,

]

上面就是django自带的7个中间件，我们想看中间件长什么样子，只需要复制中间件，用from引入，点进去看就可以了。

比如看第二个中间件：from django.middleware.sessions.middleware import sessionmiddleware，看到的结果如下：

class sessionmiddleware(middlewaremixin):

def __init__(self, get_response=none):

self.get_response = get_response

engine = import_module(settings.session_engine)

self.sessionstore = engine.sessionstore

def process_request(self, request):

session_key = request.cookies.get(settings.session_cookie_name)

request.session = self.sessionstore(session_key)

def process_response(self, request, response):

。。。。。。

我把process_response()方法下的东西省略了。但我们可以清楚的看出它就是一个继承于middlewaremixin的类。

所谓的中间件，就是存在于socket和视图函数中间的一种过滤器。浏览器客户端通过socket发送请求来，要经过一层层中间件的process_request()方法，在进入视图，视图函数执行完毕后，又要经过一层层中间件的process_response()方法，然后再通过socket发送给浏览器客户端。django服务器端的socket是由wsgiref模块封装而成的，它还帮我们把原生的数据解析成了request对象，从而在django服务器端才可以用request对象去拿值。

中间件有四个方法，分别是：

1，process_request(self,request)

2，process_response(self, request, response)

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

4，process_exception(self, request, exception)

现在我们一个一个的来分析每个方法的运用及效果，四个方法讲完了，中间件就学完了。

二、process_request()，process_response()

上面我们说了，浏览器发送请求过来，会经过一层层的process_request，具体来说，会从最上面的中间件到最下面的中间件。执行完视图函数之后，会从从下往上执行每个中间件的process_response()，之后再发送给浏览器。

通常情况下，process_request()是不会写return的，一旦某个中间件的process_request()写了return，那后面的中间件的process_request()就不会执行了，也不会到视图函数了，直接从自己的process_response()依次往上返回。

通常情况下，process_response()都要写上return response。一旦有一个中间件的process_response()没有写return response，那么数据走到这一个中间件时，数据就会丢失，后面要执行的中间件的process_response()都会没有数据。

三、process_views()

上面的第二点的执行流程是基于只有request和response的情况下的，如果加上了process_views()。首先还是先走每个中间件的request，然后走到urls.py文件，但现在不会马上去执行视图，而是先要从上往下走每个中间件的process_views(),走完之后再走视图函数，再走每个中间件的response。

第一步是process_request,第二步是process_views,第三步是执行视图函数，第四步是process_response

通常情况下，process_views 也不要加return httpresponse(‘fff’)，一旦加上了，从这个中间件以下的中间件的process_views就不会执行，视图函数也不会执行。直接跳到最下面中间件的response开始返回。

第一步是process_request,第二步是走部分的process_views,第三步是process_response

process_views()方法还可以写上回调视图函数，它会把对应的视图函数给执行了，然后返回

def process_view(self,request,callback,callback_args,callback_kwargs): response=callback(request,*callback_args,callback_kwargs)

#callback就是在经过urls.py时对应的视图函数，现在直接在process_views()直接回调视图函数，并且执行

return response

这种情况下，会在执行这个中间件的process_views，把对应的视图函数也一起执行了，然后就直接到最下面中间件从下往上执行response，返回

第一步是prosee_request，第二步是走部分的process_views，第三步是执行process_views里的回调视图函数，第四步是process_response

四、process_exception()

上面的执行流程是基于没有process_exception()情况下的，加上process_exception(),在执行完视图函数之后，后从下往上执行中间件的process_exception(),然后在从下往上执行中间件的response，然后返回。process_exception()的作用是捕获视图函数的错误。

第一步是process_request,第二步process_views,第三步执行视图函数，第四步process_exception,第五步是process_response.

五、自定义中间件

在全局创建一个文件夹middlewares，在里面创建一个m1.py

from django.utils.deprecation import middlewaremixin

class m1(middlewaremixin):

def process_request(self,request):

print(‘m1.process_request’)

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

print(‘m1.process_view’)

response=callback(request,*callback_args,callback_kwargs)

return response

def process_response(self,request,response):

print(‘m1.process_response’)

return response

记得在settings.py下的middleware加上’middleware.m1’，如下

middleware = [

‘django.middleware.security.securitymiddleware’,

‘django.contrib.sessions.middleware.sessionmiddleware’,

‘django.middleware.common.commonmiddleware’,

‘django.middleware.csrf.csrfviewmiddleware’,

‘django.contrib.auth.middleware.authenticationmiddleware’,

‘django.contrib.messages.middleware.messagemiddleware’,

‘django.middleware.clickjacking.xframeoptionsmiddleware’,

‘middleware.m1’,

]

这样，每次请求进来都会走你的中间件的process_request()，执行完视图函数后，都会走你的中间件的process_response()。

当我们多数的视图函数都要进行一个操作时，我们就可以考虑自定义一个中间件，把要执行的操作放在里面就可以不用再每个视图里面再写这些代码了。

但只有一小部分视图函数要进行某一操作，我们可以考虑自定义一个装饰器，然后在需要这操作的视图函数上面写上语法糖，也可以解决代码复用的效果。

希望与广大网友互动？？

点此进行留言吧！