Django CBV流程及源码分析

Django 实现视图的方法有两种,一种是FBV(function base view)即基于函数的视图,还一种高级的就是CBV(class base view),通过阅读源码你会发现它本质上还是基于FBV的。FBV的优点是用法和写法都比较简单适合刚开始学的同学使用,缺点就是不能用的面向对象的几大特性只用函数进行封装代码多的时候会显得代码很冗余,而CBV就很好的解决了这些问题。并且Django官方在后面的Django版本中加入了很多基于CBV的类,方便我们快速开发。我们先简单的看下Django在中路由规则的是怎么定义的,再粗略的看下一FBV,然后再讲下我们今天的重点CBV。

  1、Django中路由规则的定义,没有仔细读源码,简单的讲一下

    从这里进入url的定义:

      

   这是源码

      

   从源码可以看出,我们在定义路由规则时,第一个参数应该传入一个正则表达式,第二个参数传入的就是view,从下面的处理逻辑看,view的类型可以用两种。第一种是list 或tuple但这种是用来处理include(......)导入的url的,第二种类型就是callable类型的也就是可执行的即函数所以我们在写FBV的时候一定不要写上带上括号,因为url()函数需要的是一个可执行对象。如果传入这两种以外的类型就会报错。我们知道其实include导入 的其实也是一个callable类型的。所以我们可以确定view本质上传入的是一个可执行的对象,在启动服务时程序读取路由将view函数载入内存,接受到请求的时候就会执行这view函数并且返回数据。理解这一点很重要,这个是FBV和CBV的基础。  

  2、FBV中视图的定义和url的写法

   FBV(基于函数的视图),定义一个函数根据请求方法的不同而作出相应的处理,注意重点是将对请求的处理封装在一个函数中。看下例子

   view.py

   

   定义了一个login函数通过判断请求的方法进行返回

   url.py

   将app01中的views文件导入并将login方法传给url实现了一个FBV

  3、CBV中视图的定义和url的写法

   CBV(基于类的视图),定义一个类,继承django.views.View,将处理各种请求方式的逻辑用方法名加处理逻辑封装在方法里面,注意重点是将请求的处理封装在类里面

    eg:

form dajngo.views import VIew

class Cbv(View):

def a(self, params):
        pass

def b(self, params):

pass

      def get(self, request, *args, **kwargs):

        pass

def post(self, request, *args, **kwargs):

        pass

      def put(self, request, *args, **kwargs):

        pass       

   看下例子:

    view.py  视图的定义

      

   url.py  路由的写法

      

  4、分析3中的调用过程

在Django项目启动时路由规则开始载入内存当程序读到url(r‘^cbv/‘, views.Cbv.as_View())时重点来了,views.Cbv是我们自己定义的一个对象当我们.as_view()的时候就执行了父类的静态函数as_view方法(根据面向对象的特性可以知道是调用的父类的),我们可以根据在1中得出的结论.as_view()返回的一定是个可调用对象

看下源码中as_view函数的定义:

  

可以看到,as_view方法正如我们想的那样返回的是个可调用对象view,在路由规则载入内存后.as_view的到的其实是个view方法,在接受到请求是才会执行view方法,而view方法的返回值是self.dispatch(request, *args, **kwargs),是由一个实例对象调用的dispatch方法,我们怎么这个self是谁呢?我们可以一层一层的往上拔从而确定这个实例对象是谁。

self.dispatch(request, *args, **kwargs)是由view()方法调用的,view()方法又是由as_view()方法调用的,as_view()方法又是由views.Cbv调用的,所以我们可以确定self就是Cbv的实例对象,但我们没有定义dispatch方法所以这个dispatch方法一定在Views类中有定义。

  

这就是父类中dispatch的定义,先判断请求是否正确,以get请求为例如果请求正确的话就就利用反射到self中去找与请求方式相对应的方法,根据我们上面的分析self就是我们定义的类Cbv,handler就是我们定义的get方法最后return 我们定义的get方法的返回值。一层一层的向上冒泡,get方法将返回值给dispatch,dispatchs再将返回值给view,到了view这层就和FBV一样了。

    

     

   

  

原文地址:https://www.cnblogs.com/just-do/p/10051184.html

时间: 2024-10-10 09:49:02

Django CBV流程及源码分析的相关文章

Android应用层View绘制流程与源码分析

Android应用层View绘制流程与源码分析 1 背景 还记得前面<Android应用setContentView与LayoutInflater加载解析机制源码分析>这篇文章吗?我们有分析到Activity中界面加载显示的基本流程原理,记不记得最终分析结果就是下面的关系: 看见没有,如上图中id为content的内容就是整个View树的结构,所以对每个具体View对象的操作,其实就是个递归的实现. 前面<Android触摸屏事件派发机制详解与源码分析一(View篇)>文章的3-1

Android视图View绘制流程与源码分析(全)

来源:[工匠若水 http://blog.csdn.net/yanbober] 1 背景 还记得前面<Android应用setContentView与LayoutInflater加载解析机制源码分析>这篇文章吗?我们有分析到Activity中界面加载显示的基本流程原理,记不记得最终分析结果就是下面的关系: 看见没有,如上图中id为content的内容就是整个View树的结构,所以对每个具体View对象的操作,其实就是个递归的实现. 前面<Android触摸屏事件派发机制详解与源码分析一(

Struts2请求处理流程及源码分析

1.1 Struts2请求处理 1. 一个请求在Struts2框架中的处理步骤: a) 客户端初始化一个指向Servlet容器的请求: b) 根据Web.xml配置,请求首先经过ActionContextCleanUp过滤器,其为可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助(SiteMesh Plugin),主要清理当前线程的ActionContext和Dispatcher: c) 请求经过插件过滤器,如:SiteMesh.etc等过滤器: d) 请求经过核心过滤器Filte

Yarn任务提交流程(源码分析)

Based on Hadoop 2.7.1 JobSubmitter addMRFrameworkToDistributedCache(Configuration conf) : mapreduce.application.framework.path, 用于指定其他framework的hdfs 路径配置,默认yarn的可以不管 Token相关的方法:读取认证信息(支持二进制.json),并将其添加至相应的fileSystem中,以便以同样权限访问文件系统 copyAndConfigureFil

Spring MVC请求处理流程及源码分析

从接受请求到返回响应,Spring MVC框架的众多组件都伸胳膊挽袖子行动起来,各司其职,有条不紊地完成份内的工作.在整个框架中,DispatcherServlet处于核心的位置,它负责协调和组织不同组件,共同完成请求响应的工作.和大多数Web MVC框架一样,Spring MVC通过一个前端Servlet处理器接收所有的请求,并将具体工作委托给其它组件进行具体的处理,DispatcherServlet就是 Spring MVC的前端Servlet处理器.下面我们对Spring MVC处理请求的

【React源码分析】组件通信、refs、key和ReactDOM

React源码系列文章,请多支持:React源码分析1 - 组件和对象的创建(createClass,createElement)React源码分析2 - React组件插入DOM流程React源码分析3 - React生命周期详解React源码分析4 - setState机制React源码分析5 -- 组件通信,refs,key,ReactDOMReact源码分析6 - React合成事件系统 1 组件间通信 父组件向子组件通信 React规定了明确的单向数据流,利用props将数据从父组件传

kube-proxy源码分析

摘要:假设你对kube-proxy的工作原理有一定的了解,本文基于kubernetes v1.5代码对kube-proxy的源码目录结构进行了分析,并以iptables mode为例进行了完整流程的源码分析,给出了其内部实现的模块逻辑图,希望对你深入理解kube-proxy有所帮助. kube-proxy介绍 请参考我的另一篇博文:kube-proxy工作原理 源码目录结构分析 cmd/kube-proxy //负责kube-proxy的创建,启动的入口 . ├── app │ ├── conn

Android应用Activity、Dialog、PopWindow窗口显示机制及源码分析

[工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处,尊重劳动成果] 1 背景 之所以写这一篇博客的原因是因为之前有写过一篇<Android应用setContentView与LayoutInflater加载解析机制源码分析>,然后有人在文章下面评论和微博私信中问我关于Android应用Dialog.PopWindow.Toast加载显示机制是咋回事,所以我就写一篇文章来分析分析吧(本文以Android5.1.1 (API 22)源码为基础分析),以便大家在应

Android图片加载库Picasso源码分析

图片加载在Android开发中是非常重要,好的图片加载库也比比皆是.ImageLoader.Picasso.Glide.Fresco均是优秀的图片加载库. 以上提到的几种图片加载库各有特色.用法与比较,网上已经很多了. 出于学习的角度,个人认为从Picasso入手较好.代码量小,同时API优美,很适合我们学习. 今天笔者就Picasso的源码进行分析,抛出一些图片加载的技术细节供园友参考. PS:建议园友先大致看一下源码. 我们对图片加载的要求 1.加载速度要快 2.资源消耗要低 3.加载图片不