广州住房和城乡建设部网站网站统计分析

当前位置： 首页 > news >正文

广州住房和城乡建设部网站,网站统计分析,浙江省住房和建设厅网站,官网争锋文章目录 MVC与MTV模型MVCMTV Django目录结构Django请求生命周期流程图路由控制路由是什么路由匹配反向解析路由分发 视图层视图函数语法reqeust对象属性reqeust对象方法 MVC与MTV模型 MVC Web服务器开发领域里著名的MVC模式#xff0c;所谓MVC就是把Web应用分为模型(M#… 文章目录 MVC与MTV模型MVCMTV Django目录结构Django请求生命周期流程图路由控制路由是什么路由匹配反向解析路由分发 视图层视图函数语法reqeust对象属性reqeust对象方法 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和TemplateMTV的响应模式如下所示 一般是用户通过浏览器向我们的服务器发起一个请求(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?spm1001.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?spm1001.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, kwargsNone, nameNone)第一个参数精准路径字符串可以使用转换器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,nameindex),视图函数from django.shortcuts import HttpResponse,reversedef index(request):reverse(index) # 定义路径传入的name参数对应的字符串2.有转化器的情况path(index/str:name, views.index,nameindex),视图函数from django.shortcuts import HttpResponse,reversedef index(request):reverse(indexkwargs{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、POSTreqeust.FILES 一个类似于字典的对象包含所有的上传文件信息。request对象不常用的属性request.cookiereqeust.sessionreqeust.content_type提交的编码格式urlencodedform表单jsonform-datatext/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 和 CONTENTTYPE 之外请求中的任何 HTTP 首部转换为 META 的键时都会将所有字母大写并将连接符替换为下划线最后加上 HTTP 前缀。所以一个叫做 X-Bender 的头部将转换成 META 中的 HTTP_X_BENDER 键。用户自定义写的例如namejack取request.META.get(HTTP_NAME) # 前面加上HTTP_把自定义的转成大写reqeust对象方法 1.HttpRequest.get_full_path()返回 path如果可以将加上查询字符串。例如/music/bands/the_beatles/?printtrue注意和path的区别http://127.0.0.1:8001/order/?namelqzage102.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) 装饰你的视图以让响应能够正确地缓存。