学习知识随笔（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)
	第一个参数：
		精准路径，字符串
		可以使用转换器：''  ''
		例子：
			path('index///',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,reverse
		def index(request):
			reverse('index') # 定义路径传入的name参数对应的字符串
			
	2.有转化器的情况：
		path('index/', views.index,name='index'),
		'视图函数'
		from django.shortcuts import HttpResponse,reverse
		def 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'

	路由分发需要使用到关键字include
	from django.urls. import path,include
	主路由：
		urlpatterns = [
		    path('admin/', admin.site.urls),
		    path('app01/', include('app01.urls')),
		]

	然后需要再应用里面建立一个urls.py文件
	充当子路由
	from django.urls import path
	from app01 import views
	
	urlpatterns = [
	    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.cookie
		reqeust.session
		reqeust.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=10


2.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') 装饰你的视图以让响应能够正确地缓存。