Python——Django框架(八)、Django请求生命周期——HTTP请求、Django生命周期之FBV和CBV、类(CBV)的反射、请求周期的响应内容、基本流程总结

Python——Django框架(八)、Django请求生命周期

一、HTTP请求

1、传递

请求跟响应默认传递的都是字符串,这个大字符串分成了两部分:

请求字符串
响应字符串

a、请求字符串

比如:
打开一个博客园的网站,查看里面的请求头

请求头:
在这里插入图片描述
上面的 Request Headers 就是请求头,会把这么多东西都发过去。还有一个就是请求体。

请求体:
接着我们可以尝试登录注册:
在这里插入图片描述

里面有个form Data,这个就是请求内容。

这两部分会发到我们的服务器端,服务端接收的时候,这整个字符串,需要把它们分开。请求头跟请求体通过换行符 ( \r\n\r\n ) 分隔。

我们还能发现在请求头里面还有个叫 Cookie 的东西。

b、相应字符串

服务端接收到以后,需要响应,给用户(客户端)返回字符串,同样有响应头跟响应体:

响应头:
在这里插入图片描述
上面的 Response Headers 就是响应头

有了响应头自然还有响应体:
在这里插入图片描述

上面的 Response 就是响应体。

而有的响应体则是Html:
在这里插入图片描述
同样的,响应头跟响应体之间也是通过换行符( \r\n\r\n )分隔。

二、Django生命周期之FBV和CBV

1、请求头与请求体的补充

当用户在浏览器上点下这个URL之后,在Django后台都发生了什么? 这叫一个请求的生命周期。

上面的请求头并没有说完整,其实还有下面这个:
在这里插入图片描述
如果从URL里面取数据,则是GET方式,如果在请求体里面拿数据,则是POST方式(默认是通过POST方式):
在这里插入图片描述

请求体里面的东西默认是字符串,这个POST帮我们把请求体里面的东西转换成了字典。

request.post 是从 request.body 分析出来的, request.body 传递的是原生字符串的内容,在内部帮我们转换成 request.post 。

2、从上到下的路由匹配

先来看一个例子:

下面是View 层的函数:
在这里插入图片描述

然后是路由:
在这里插入图片描述

然后开始访问:
在这里插入图片描述
访问 inx 没问题

接着访问inxd:
在这里插入图片描述

可以发现还是 inx

这是因为路由访问是从上到下访问,被 inx 匹配了,第一个匹配成功之后,就不匹配了(inxd 失效),在这种情况下,我们可以附加 正则表达式 ,加个 $ 符号,意思是以…结尾,只有写全了这个URL,才会匹配这个网址:
在这里插入图片描述
或者这样:
在这里插入图片描述
题外话:

路由引导的函数不一定要放在View文件里面,urls路由文件里面一样可以:
在这里插入图片描述

3、FBV和CBV

a、了解FBV和CBV

可以看到,一个url对应一个视图函数,这种就叫 FBV 模式。
还有一种叫 CBV模式,这种对应的是一个 类,类 class,所以叫 CBV模式。
.
内容回顾:
在这里插入图片描述

b、例子

到目前为止使用的 FBV模式 都是这样:

在这里插入图片描述

在这里插入图片描述
然后,CBV模式是这样:
首先路由这块就开始不同,假设我们要写的类的名字是 CBV ,则这样写:
在这里插入图片描述
可以看到后面多了 as_view(),这是固定写法。

然后到view层这里,与方法不同的是,如果要写类,需要继承一些方法才能具备这种功能:
在这里插入图片描述在这里插入图片描述
可以看到,类里面,可以直接使用 get 方法 与 post 方法。

4、CBV的POST与GET执行哪个?

看下图:
在这里插入图片描述
可以看到,如果是CBV模式,来到了类里面,类里面有方法,那么这时候又该去哪个方法里面呢?

这时就要回到请求头里面,请求头里面有这么一个东西:
在这里插入图片描述
如果是用POST形式发的请求,则执行POST方法;GET同理。

cbv

三、FBV与CBV选哪个?

FBV与CBV用哪个?
答:不知道,哪个适合就用哪个,你想用哪个就用哪个,哪个能完成需求就用哪个。

四、类(CBV)里面的反射

1、反射

类里面这么多方法,怎么找到POST方法(GET同理)并执行这个方法?

遍历是不可能的,答案是通过前面学过的 反射 。

所以,Django内部已经帮我们做好了。内部的 dispatch()方法:
在这里插入图片描述
通过反射帮我们找到 GET 和 POST 方法。

所以整个流程是这样:
在这里插入图片描述
此时的CBV没有 dispatch方法,则会往父类里面去找。

2、数据的返回(dispatch的额外处理,自定制功能)

我们先简化一下返回的流程:
在这里插入图片描述
数据的返回要经过 dispatch ,经过这个之后再返回给用户(中间还有很多流程,先简化)。

然后这么写:
在这里插入图片描述
我们把内部的 dispatch方法提取出来,这么用肯定不行,但是我们可以用他父类的方法:
在这里插入图片描述
这么写的话就跟原来的功能一样,

这时我们写一个简单的语句:
在这里插入图片描述
尝试后可以发现,无论是 GET 方法还是 POST 方法,都会输出这个语句,这意味着,如果以后有 GET 方法跟 POST 方法都要执行某个功能,可以写在这个位置。

比如在执行 GET或者 POST 之前,需要写一条日志,可以在这个位置写,不需要写多遍。再比如:登录验证。

五、请求生命周期之响应内容

1、响应头与响应体

如果是GET方式请求,则请求头有东西,请求体是空的。

除了POST跟GET,还有其它请求方式:
在这里插入图片描述
一般写的 HttpResponse 里面加的字符串放在响应体里面,那么怎么加响应头呢?
在这里插入图片描述
这么操作完之后,就会往响应头里面加一个 h1 v1:
在这里插入图片描述
还有之前讲的 Cookie ,怎么写 Cookie呢?
在这里插入图片描述

这时就会往响应头里面加了 Cookie:
在这里插入图片描述

六、基本的请求流程总结

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_41824825/article/details/116203324