图片转自:https://www.cnblogs.com/li-li/p/9892583.html
django的生命周期:
1)client代表浏览器,浏览器内部为我们封装了socket,Django的WSGI模块也封装了socket;分析:
2)当用户在浏览器中输入url时,浏览器会生成请求头和请求体发给服务端,请求头和请求体中会包含浏览器的动作(action),这个动作通常为get或者post, 体现在url之中;
3)请求到达Django服务器后,首先,WSGI根据http请求协议进行解包并将请求信息封装到HttpRequest对象中;
4)再依次经过Django的中间件的process_request方法(Django自带7个中间件,每个中间件都是一个类,类中一定有一个process_request方法);
5)然后通过url控制器分发后,执行对应的视图函数,视图函数中可以根据请求查询相应的数据,得到的数据可以再传给模板,经过render方法渲染后返回;
6)返回时再依次经过中间件的process_response方法;
7)再经过WSGI模块,WSGI将按照http协议响应格式封装响应信息,最后返回给客户端(浏览器);
8)客户端浏览器接收到返回的数据,经过渲染后显示给用户;
中间件:
中间件在django中就是一个类, 是全局范围内改变django输入和输出的.
可以自定义中间件必须继承MiddlewareMixin, 还需要导入from django.utils.deprecation import MiddlewareMixin.
执行时间: 在视图函数执行之前
参数: request ----> 跟视图函数中是同一个
执行顺序: 按照在setting里的注册顺序 顺序执行
返回值:
当返回的值是None的时候, 正常流程
当返回的值是HttpResponse对象时, 就会直接把这个HttpResponse对象返给浏览器, 所以不再执行中间件文件中这个process_request后面的其他的process_request方法; 也不会执行视图函数; 直接执行当前的中间件的process_response方法
总结:
-
中间件process_request方法是在执行视图函数之前执行的.
-
当配置多个中间件的时候, 会按照在MIDDLEWARE中的注册顺序, 也就是列表的索引值, 从前到后依次执行
-
不同的中间件之间传递的request都是同一个对象
执行时间: 在视图函数执行之后
参数:
request ----> 跟视图函数中的是同一个
response ---> 视图函数返回的HttpResponse对象.
执行顺序: 按照在setting里的注册顺序 倒序执行 也就是说第一个中间件的process_request方法首先执行,而它的process_response方法最后执行, 最后一个中间件的process_request方法最后执行,而它的process_response方法最先执行
返回值: 是response对象, 必须是响应对象
执行时间: 在process_request执行之后, 在视图函数执行之前,
参数:
request ----> 跟视图函数中的是同一个
view_func---> 视图函数
view_args---->视图函数的位置参数
view_kwargs--->视图函数的关键字参数
执行顺序: 按照在setting里的注册顺序 顺序执行
返回值:
None 正常执行
HttpResponse对象: 不执行后面中间件的process_view方法, 不执行视图函数, 直接执行最后一个中间件中的process_response方法, 后面的正常执行
中间件的流程: