django生命周期流程图与django路由层

目录

• 一、django请求生命周期流程图
• 二、django路由层
  • 1.路由匹配
  • 2.转换器
  • 3.正则匹配
    • 不同版本的区别
    • 正则匹配斜杠导致的区别
  • 4、正则匹配的无名有名分组
    • 分组匹配
    • 无名分组
    • 有名分组
• 三、反向解析
  • 1.引入反向解析
  • 2.反向解析使用
  • 3.有名无名反向解析（动态路由反向解析）
• 四、路由分发
• 五、名称空间
  • 方式1:名称空间
  • 方式2:别名不冲突即可

一、django请求生命周期流程图

1、Django请求的生命周期的含义

Django请求的生命周期是指：当用户在浏览器上输入url到用户看到网页的这个时间段内,Django后台所发生的事情。**

2、Django请求的生命周期图解及流程

这个图很重要 无论是学习阶段还是复习阶段

学习流程
通过这个生命周期图我们可以了解到接下去的学习流程为：路由层、视图层、模板层、模型层、组件、BBS项目

• Django自带的web服务网管接口是wsgiref，因为他能承受的并发量特别低，因此我们在项目中会换成uwsgi，它的并发量比wsgiref高很多。
• WSGI与wsgiref和uwsgi之间的关系是：WSGI是协议，wsgiref和uwsgi是实现协议功能的模块。
• 中间件可以看成保安，数据的进出都会经过他的检查。
• 路由层就是存放网址后缀与视图之间的关系。
• 视图层存放功能函数，通过函数调用模版层中的html网页，同时在函数内通过models.py建立与数据库的交互。

二、django路由层

1.路由匹配

django2.X及以上 path第一个参数写什么就匹配什么
django1.X第一个参数是正则表达式

无论什么版本django都自带加斜杠后缀的功能，也可以取消

ps：当我们在用网址访问网页的时候，有些网址需要在末尾加上‘/’符号，有些则不用，但是这些不用‘/’结尾的网址在跳转后，末尾自动补了一个‘/’。我们在配置文件中修改APPEND_SLASH 配置就可以设置这个功能，当他的值为True，就会自动添加斜杠进行匹配，如果改成False就不会自动匹配。

APPEND_SLASH = False

2.转换器

什么时候用转换器？

• 当网址后缀不固定的时候 可以使用转换器来匹配

如何写path转换器？

• path('login/<int:year>/<str:desc>/', views.login)
  

具体情况分析

• 正常情况下很多网站都会有很多相似的网址 如果我们每一个都单独开设路由不合理，因此使用转换器动态匹配

django2.X及以上版本路由动态匹配有转换器(五种)

• str：匹配除路径分隔符外的任何非空字符串。

• int：匹配0或者任意正整数。

• slug：匹配任意一个由字母或数字组成的字符串。

• uuid：匹配格式化后的UUID。

• path：能够匹配完整的URL路径

ps:还支持自定义转换器(自己写正则表达式匹配更加细化的内容)

转换器：

将对应位置匹配到的数据转换成固定的数据类型（如果数据类型不匹配会报错）。

path('index/<str:info>/', views.index_func) 
# index_func(实参request对象,info='转换器匹配到的类型转换之后的内容')
path('index/<str:info>/<int:id>/', views.index_func)
# index_func(实参request对象,info='转换器匹配到的类型转换之后的内容',id='转换器匹配到的类型转换之后的内容')

3.正则匹配

不同版本的区别

django1.x版本用的是url的形式直接使用正则进行匹配网址后缀，代码如下：

from django.conf.urls import url

urlpatterns = [
     url(正则表达式, views视图函数，参数，别名),
]

django2.X及以上版本则替换成了path，django1.X路由匹配使用的是url() 功能与django2.X及以上的re_path()一致，第一个参数是正则。

from django.urls import path

urlpatterns = [
    path('articles/2003/', views.special_case_2003),
    path('articles/<int:year>/', views.year_archive),
	path('articles/<int:year>/<int:month>/', views.month_archive),
	path('articles/<int:year>/<int:month>/<slug:slug>/', views.article_detail),
	re_path('^test/$', views.test)
]

正则匹配斜杠导致的区别

正则匹配的时候要区分斜杠的作用，如果后面不写斜杠，匹配的结果就是网址中间有符合匹配条件的内容就会跳转，如果加了斜杠结尾，就是连着斜杠一起匹配（相当于匹配网址的结尾符合条件的网址）。

ps：正则匹配的本质是只要第一个正则表达式能够从用户输入的路由中匹配到数据就算匹配成功会立刻停止路由层其他的匹配直接执行对应的视图函数

4、正则匹配的无名有名分组

分组匹配

分组匹配就是使用小括号，产生分组优先，然后括号内匹配到的数据会当成参数传递给对应的函数。

无名分组

re_path('^test/(\d{4})/', views.test)

re_path('^test/(\d{4})/(.*?)/', views.test)
# test(实参request对象,括号内正则匹配到的内容)

会将括号内正则匹配到的内容当做位置参数传递给视图函数，在函数的参数中写位置参数接收即可。

有名分组

re_path('^test/(?P<year>\d{4})/', views.test)
    
re_path('^test/(?P<year>\d{4})/(?P<others>.*?)/', views.test)
# test(实参request对象,year='\d{4}匹配到的内容',others='.*?匹配到的内容')

re_path('^test/(\d{4})/(?P<others>.*?)/', views.test)
# test(实参request对象,year='\d{4}匹配到的内容',others='.*?匹配到的内容')

会将括号内正则匹配到的内容当做关键字参数传递给视图函数，也需要使用位置参数接收。

ps：注意上述的有名分组和无名分组不能混合使用!!!

三、反向解析

1.引入反向解析

    页面上的一些超链接、重定向等路由都是写死的，一旦路由发生变化则会导致所有页面相关链接失效，而反向解析就是用来防止出现该问题的。

2.反向解析使用

方式一：路由对应关系起别名

在路由中给对应关系再取一个别名这样网页中使用时直接调用这个别名，就相当于调用了对应的后缀

路由层：
    path('后缀',views.视图函数,name='关系名')

方式二：使用反向解析语法

html页面与后端都可以进行调用

html调用：
    {% url '关系名' %}

后端跳转调用（需要先导入模块）：
    from django.shortcuts import reverse
    reverse('关系名')

ps：反向解析的操作三个方法都一样：path()、re_path()、url()

3.有名无名反向解析（动态路由反向解析）

    如果路由里面有不确定的因素那么在使用反向解析的时候必须人为传递数据，且有几个不确定因素就得穿几个值

eg：
    路由层：
    path('func1/<str:others>/', views.func1_func, name='func1_view')
    视图层：
    reverse('func1_view', args=('嘿嘿嘿',))
    html页：
    {% url 'func1_view' 'jason' %}

ps：html页面上模板语法（因为定义动态路由的时候有一部分是动态匹配，所以需要指定一个参数）

四、路由分发

• django支持每个应用都可以有自己独立的路由层、静态文件、模板层。基于该特性多人开发项目就可以完全解耦合，之后利用路由分发还可以整合到一起

• 多个应用都有很多路由与视图函数的对应关系 这个时候可以拆分到各自的路由层中

• 说的直白一点，路由分发就是把Django项目中的路由信息分配到每个应用中，然后在项目的路由文件中导入应用中的路文件即可正常使用。

使用路由分发之前 总路由直接干路由与视图函数的匹配

path('index/', index)

使用路由分发之后 总路由只按照应用名分配匹配方向

path('app01/',include('app01.urls')),
path('app02/',include('app02.urls')),

应用中的子路由：

path('after/',views.after)  # app01

path('after/',views.after)  # app02

总结：

• 路由分发解决的就是项目的总路由匹配关系过多的情况
• 利用路由分发之后 总路由不再处理路由与视图函数的直接对应关系
• 总路由而是做一个分发处理(识别当前url是属于那个应用下的 直接分发对应的应用去处理)

五、名称空间

路由分发之后，针对相同的别名能否自动反向解析出不同的应用前缀？

经过测试，默认情况下是无法直接识别应用前缀的。

如果想要正常识别区分有两种方式

方式1:名称空间

在总路由中增加一个名称空间（在Django1和Django2及以上版本有区别，Django1用的是url）

Django2及以上版本

path('app01/', include(('app01.urls', 'app01'), namespace='app01')),

path('app02/', include(('app02.urls', 'app02'), namespace='app02')),

反向解析中的使用方式

reverse('app01:index_view')
reverse('app02:index_view')

Django1中的使用方式

# 1.总路由增加一个名称空间
url(r'^app01/',include('app01.urls',namespace='app01')), # 创建名称空间app01
url(r'^app02/',include('app02.urls',namespace='app02'))  # 创建名称空间app02

# 2.子路由app01
urlpatterns = [
    url(r'^reg/',views.reg,name='reg')
]
# 后端
def reg(request):
    print(reverse('app01:reg'))
    return HttpResponse('app01: reg')

# 前端
{% url 'app01:reg' %}

# 3.子路由app02
urlpatterns = [
    url(r'^reg/',views.reg,name='reg')
]

# 后端
def reg(request):
    print(reverse('app02:reg'))
    return HttpResponse('app02: reg')
# 前端
{% url 'app02:reg' %}

方式2:别名不冲突即可

多个应用别名不冲突可以用应用名作为别名的前缀

path('index/', views.index, name='app01_index_view')

path('index/', views.index, name='app02_index_view')