学习知识随笔（Django）

MVC与MTV模型

MVC

Web服务器开发领域里著名的MVC模式，所谓MVC就是把Web应用分为模型(M：数据层)，控制器(C：逻辑判断)和视图(V：用户所看的)三层，他们之间以一种插件式的、松耦合的方式连接在一起，模型负责业务对象与数据库的映射(ORM)，视图负责与用户的交互(页面)，控制器接受用户的输入调用模型和视图完成用户的请求，其示意图如下所示：

MTV

Django的MTV模式本质上和MVC是一样的，也是为了各组件间保持松耦合关系，只是定义上有些许不同，Django的MTV分别是值：

• M 代表模型（Model）：负责业务对象和数据库的关系映射(ORM)。(M 就是 MVC 的 M)
• T 代表模版（Template）：负责如果把页面展示给用户(HTML)。(T 就是 MVC 的 V)
• V 代表视图（View）：负责业务逻辑，并在适当时候调用Model和Template (V+路由 就是 MVC 的 C)

除了以上三层之外，还需要一个URL分发器，它的作用是将一个个URL的页面请求分发给不同的View处理，View再调用相应的Model和Template，MTV的响应模式如下所示：

一般是用户通过浏览器向我们的服务器发起一个请求(request)，这个请求回去访问视图函数，（如果不涉及到数据调用，那么这个时候视图函数返回一个模版也就是一个网页给用户），视图函数调用模型，模型去数据库查找数据，然后逐级返回，视图函数把返回的数据填充到模版中的空格中，最后返回页面给用户

---

Django目录结构

		django项目目录项目同名文件夹__init__.py  		很少用 主要做一些冷门配置settings.py    		项目的全局配置文件urls.py		   		路由文件，写地址的后缀和视图函数的对应关系wsgi.py		 		django服务 基本不用manage.py			django的启动文件、入口文件templates文件夹		模版文件，存储项目所需的html文件应用名文件夹(可以有多个)migrations文件夹  	orm相关(数据库打交道的记录)__init__.py  		很少用 主要做一些冷门配置admin.py		 	django自带的后台管理系统apps.py				创建应用之后用于应用的注册models.py			模型层，存储与数据库表相关的类tests.py			自带的测试文件views.py		 	视图文件。存储业务相关的逻辑代码(函数、类)db.sqlite3			自带的小型数据库urls.py				路由层views.py			视图层templates			模板层models.py   		模型层

更多Django基本操作可以去看我的这篇博客https://blog.csdn.net/achen_m/article/details/134296792?spm=1001.2014.3001.5501

---

Django请求生命周期流程图

	django的生命周期是从用户发送HTTP请求数据到网站响应的过程。整个过程的流程：1.首先，用户在浏览器输入一个URL，发送一个请求2.在django中有一个封装的socket的方法模块wsgiref，监听端口接收request请求，并且封装传送到中间件中。3.在由中间件传输到路由系统中进行路由分发，匹配相对应的视图函数4.将reqeust请求传输到视图函数中进行逻辑处理。5.调用models中表对象，然后通过ORM操作数据库拿到数据，同时去templates中去相应的模版文件中进行渲染6.然后返回到中间件中，进行response响应返回数据到wsgiref中进行封装后再返回给浏览器展示给用户 

---

路由控制

此处只做补充知识，想看更多可查看我的这篇博客了解https://blog.csdn.net/achen_m/article/details/134377889?spm=1001.2014.3001.5501

路由是什么

URL配置(URLconf)就像Django 所支撑网站的目录。它的本质是URL与要为该URL调用的视图函数之间的映射表；你就是以这种方式告诉Django，对于客户端发来的某个URL调用哪一段逻辑代码对应执行(请求路径和要执行的视图函数的关系)

路由匹配

此处只说2.X版本以上使用的关键字path，想看1.X的可以前去上面标题处的连接

	在django2.x及以上版本：path第一个参数写什么就匹配什么(精准匹配)，匹配到直接执行对应的视图函数path('admin/',函数名),  '这种写法不支持正则表达式'当然2.x版本也有可以使用正则匹配的方式：re_path(正则表达式,函数名) '其作用和django1.x的url使用效果一模一样''但是因为有转换器，基本就用不上re_path这个关键字，而且正则匹配本就不是那么的安全'

---

path的详细使用

	urlpatterns = [path('admin/', views.admin),]等价于：_path(route, view, kwargs=None, name=None)第一个参数：精准路径，字符串可以使用转换器：'<int:pk>'  '<str:name>'例子：path('index/<int:year>/<str:info>/',views.index)转换器有几个名字，那么视图函数的形参就必须对应视图层：def index(request,year,info):print(year,info)return HttpResponse('from index')第二个参数：视图函数的内存地址，不要加括号1.路由一旦匹配成功，就会执行，你写的这个视图函数(request)，并且会把request对象传入2.如果有分组的参数[有名分组、无名分组]，或者转换器的参数，都会被传递到视图函数中作为参数'''总结：需要放视图函数内存地址------》视图函数的第一个参数是固定的，必须是reqeust，后续的参数取决于写没写转换器或者写没写有名分组、无名分组'''第三个参数：kwargs 是给视图函数传递默认参数第四个参数：是路径的别名---》主要用于反向解析得到该路径

而re_path除了第一个参数不一样以外，其他完全和path是一样的。re_path第一个参数是正则表达式

现在基本很少使用re_path，因为危险性比较大，原来之所以使用就是为了使用正则匹配分组出参数，现在path可以通过转换器就能完成这个操作，所以基本不使用re_path

---

反向解析

在使用Django 项目时，一个常见的需求是获得URL 的最终形式，以用于嵌入到生成的内容中（视图中和显示给用户的URL等）或者用于处理服务器端的导航（重定向等）。人们强烈希望不要硬编码这些URL（费力、不可扩展且容易产生错误）或者设计一种与URLconf 毫不相关的专门的URL 生成机制，因为这样容易导致一定程度上产生过期的URL。

反向解析为的就是防止路由经常变动，这样我们页面的链接、或者函数的重定向就能动态获取到路由可接收的URL。

此处也仅用path来讲述

	'反向解析，用于视图函数中、用于模版中'1.没有转换器的情况：path('index/', views.index,name='index'),'视图函数'from django.shortcuts import HttpResponse,reversedef index(request):reverse('index') # 定义路径传入的name参数对应的字符串2.有转化器的情况：path('index/<str:name>', views.index,name='index'),'视图函数'from django.shortcuts import HttpResponse,reversedef index(request):reverse('index'，kwargs={'name':'jack'})'最后生成的路径：URL/index/jack'

---

路由分发

django是专注于开发应用的，当一个django项目特别庞大的时候所有的路由与视图函数映射关系全部写在总的urls.py很明显太冗余不便于管理，其实django中的每一个app应用都可以有自己的urls.py、static文件夹、templates文件夹，基于上述特点，使用django做分组开发非常的简便。

可以分开写多个app应用，最后再汇总到一个空的Django项目然后使用路由分发将多个app应用关联起来。

未使用路由分发前：所有请求都由主路由转发到对应视图函数，全部都在一个urls.py文件内。

为什么默认路由匹配能匹配到urls.py文件呢？是因为在settings配置文件中配置了ROOT_URLCONF = 'django_项目名.urls'

	路由分发需要使用到关键字includefrom django.urls. import path,include主路由：urlpatterns = [path('admin/', admin.site.urls),path('app01/', include('app01.urls')),]然后需要再应用里面建立一个urls.py文件充当子路由from django.urls import pathfrom app01 import viewsurlpatterns = [path('index/',views.index),]

---

视图层

django视图层：Django项目下的views.py文件，它的内部是一系列的函数或者是类,用来处理客户端的请求后处理并返回相应的数据

视图层，熟练掌握两个对象即可：请求对象(request)和响应对象(HttpResponse)

视图函数语法

	'视图函数必须要有一个reqeust参数，并且必须要返回一个HttpResponse对象'def index(reqeust):return HttpResponse('hello,world')

reqeust对象属性

django将请求报文中的请求行、首部信息、内容主体封装成 HttpRequest 类中的属性。 除了特殊说明的之外，其他均为只读的

	'它是http请求(数据包----》字符串形式)-----》拆分成了django中的reqeust对象'request对象常用的属性：request.GET		一个类似于字典的对象，包含 HTTP GET 的所有参数。详情请参考 QueryDict 对象。reqeust.POST	一个类似于字典的对象，如果请求中包含表单数据，则将这些数据封装成 QueryDict 对象。reqeust.body	一个字符串，代表请求报文的主体。在处理非 HTTP 形式的报文时非常有用，例如：二进制图片、XML,Json等。但是，如果要处理表单数据的时候，推荐还是使用 HttpRequest.POST 。request.path 	一个字符串，表示请求的路径组件（不含域名）。例如："/music/bands/the_beatles/"request.method	一个字符串，表示请求使用的HTTP 方法。必须使用大写。例如："GET"、"POST"reqeust.FILES	一个类似于字典的对象，包含所有的上传文件信息。request对象不常用的属性：request.cookiereqeust.sessionreqeust.content_type：提交的编码格式：'urlencoded（form表单），json，form-data，text/plain(一般不用，浏览器默认格式)'reqeust.META：请求头中的数据一个标准的Python 字典，包含所有的HTTP 首部。具体的头部信息取决于客户端和服务器，下面是一些示例：取值：CONTENT_LENGTH —— 请求的正文的长度（是一个字符串）。CONTENT_TYPE —— 请求的正文的MIME 类型。HTTP_ACCEPT —— 响应可接收的Content-Type。HTTP_ACCEPT_ENCODING —— 响应可接收的编码。HTTP_ACCEPT_LANGUAGE —— 响应可接收的语言。HTTP_HOST —— 客服端发送的HTTP Host 头部。HTTP_REFERER —— Referring 页面。HTTP_USER_AGENT —— 客户端的user-agent 字符串。QUERY_STRING —— 单个字符串形式的查询字符串（未解析过的形式）。REMOTE_ADDR —— 客户端的IP 地址。REMOTE_HOST —— 客户端的主机名。REMOTE_USER —— 服务器认证后的用户。REQUEST_METHOD —— 一个字符串，例如"GET" 或"POST"。SERVER_NAME —— 服务器的主机名。SERVER_PORT —— 服务器的端口（是一个字符串）。从上面可以看到，除 CONTENT_LENGTH 和 CONTENT_TYPE 之外，请求中的任何 HTTP 首部转换为 META 的键时，都会将所有字母大写并将连接符替换为下划线最后加上 HTTP_  前缀。所以，一个叫做 X-Bender 的头部将转换成 META 中的 HTTP_X_BENDER 键。'''用户自定义写的例如：name=jack取：request.META.get('HTTP_NAME')  # 前面加上HTTP_把自定义的转成大写'''

reqeust对象方法

1.HttpRequest.get_full_path()返回 path，如果可以将加上查询字符串。例如："/music/bands/the_beatles/?print=true"注意和path的区别：http://127.0.0.1:8001/order/?name=lqz&age=102.HttpRequest.is_ajax()如果请求是通过XMLHttpRequest 发起的，则返回True，方法是检查 HTTP_X_REQUESTED_WITH 相应的首部是否是字符串'XMLHttpRequest'。大部分现代的 JavaScript 库都会发送这个头部。如果你编写自己的 XMLHttpRequest 调用（在浏览器端），你必须手工设置这个值来让 is_ajax() 可以工作。如果一个响应需要根据请求是否是通过AJAX 发起的，并且你正在使用某种形式的缓存例如Django 的 cache middleware，你应该使用 vary_on_headers('HTTP_X_REQUESTED_WITH') 装饰你的视图以让响应能够正确地缓存。