Django的rest_framework的视图之基于ModelViewSet视图源码解析

前言

今天一直在整理Django的rest_framework的序列化组件,前面一共写了2篇博客,前面的博客给的方案都是一个中间的状态的博客,其中有很多的冗余的代码,如果有朋友不清楚,可以先看下我前面的博客

第一篇,使用minix类来实现序列化和反序列化

https://www.cnblogs.com/bainianminguo/p/10463741.html

第二篇,使用通用的类的方法实现序列化和反序列化

https://www.cnblogs.com/bainianminguo/p/10463784.html

这篇我给大家介绍一个终极方案,基于ModelViewSet的序列化和反序列化的方案和源码解析

正文

终极方案之需要一个类就可以分别处理model对象的删改查操作,和queryset对象的增和查操作

先把具体的代码贴上来,让大家有一个整体的概念,然后我一一给大家分析

一、代码

1、首先urls文件

from django.conf.urls import url
from django.contrib import admin
from django.conf.urls import include
from app1 import views
app_name = "app1"
urlpatterns = [
    url(r‘^test/‘, views.test),
    url(r‘^test_cbv/‘, views.test_cbv.as_view(),name="test1"),
    url(r‘^test_rest/‘, views.Rest_view.as_view(),name="test2"),
    url(r‘^book_cbv/‘, views.Book_cbv.as_view(),name="test3"),
    url(r‘^publish_detail_cbv/(?P<id>\d+)‘, views.Pub_detail_cbv.as_view(),name="publish_url_name"),
    url(r‘^book_detail_cbv/(?P<id>\d+)‘, views.Book_detail_cbv.as_view(),name="test4"),
    # url(r‘^autherdetail/(?P<id>\d+)‘, views.Book_detail_cbv.as_view(), name="autherdetail"),
    # url(r‘^auther/‘, views.Book_cbv.as_view(),name="auther"),

    url(r‘^autherdetail/(?P<pk>\d+)/‘, views.AutherModelCBV.as_view({"get":"retrieve","delete":"destroy","put":"update"}), name="autherdetail"),
    url(r‘^auther/‘, views.AutherModelCBV.as_view({"get":"list","post":"create"}),name="auther"),
]

  

我们用的url是最后两条

我们仔细观察一下,这里的url和之前有3个地方不一样,我一一给大家指出来

a、两个url对应的类是相同的类

b、as_view这个方法有参数,这个参数是一个字典

c、对于model对象的url的url中的变量的名称是pk,之前我们用的id

2、序列化类的代码

class authermodelserializer(serializers.ModelSerializer):
    class Meta:
        model = models.Auther
        fields = "__all__"

序列化的类的代码和之前的保持一致,没有任何改变

3、视图类的代码

from rest_framework import viewsets

class AutherModelCBV(viewsets.ModelViewSet):
    queryset = models.Auther.objects.all()
    serializer_class = authermodelserializer

  

我们可以看到这个类非常的简单,这个类继承了一个新的类,我们之前没有用过这个类:viewsets.ModelViewSet

二、流程和源码解析

1、从url的as_view方法开始解读

as_view的源码

    @classonlymethod
    def as_view(cls, actions=None, **initkwargs):
        """
        Because of the way class based views create a closure around the
        instantiated view, we need to totally reimplement `.as_view`,
        and slightly modify the view function that is created and returned.
        """
        # The name and description initkwargs may be explicitly overridden for
        # certain route confiugurations. eg, names of extra actions.
        cls.name = None
        cls.description = None

        # The suffix initkwarg is reserved for displaying the viewset type.
        # This initkwarg should have no effect if the name is provided.
        # eg. ‘List‘ or ‘Instance‘.
        cls.suffix = None

        # The detail initkwarg is reserved for introspecting the viewset type.
        cls.detail = None

        # Setting a basename allows a view to reverse its action urls. This
        # value is provided by the router through the initkwargs.
        cls.basename = None

        # actions must not be empty
        if not actions:
            raise TypeError("The `actions` argument must be provided when "
                            "calling `.as_view()` on a ViewSet. For example "
                            "`.as_view({‘get‘: ‘list‘})`")

        # sanitize keyword arguments
        for key in initkwargs:
            if key in cls.http_method_names:
                raise TypeError("You tried to pass in the %s method name as a "
                                "keyword argument to %s(). Don‘t do that."
                                % (key, cls.__name__))
            if not hasattr(cls, key):
                raise TypeError("%s() received an invalid keyword %r" % (
                    cls.__name__, key))

        # name and suffix are mutually exclusive
        if ‘name‘ in initkwargs and ‘suffix‘ in initkwargs:
            raise TypeError("%s() received both `name` and `suffix`, which are "
                            "mutually exclusive arguments." % (cls.__name__))

        def view(request, *args, **kwargs):
            self = cls(**initkwargs)
            # We also store the mapping of request methods to actions,
            # so that we can later set the action attribute.
            # eg. `self.action = ‘list‘` on an incoming GET request.
            self.action_map = actions

            # Bind methods to actions
            # This is the bit that‘s different to a standard view
            for method, action in actions.items():
                handler = getattr(self, action)
                setattr(self, method, handler)

            if hasattr(self, ‘get‘) and not hasattr(self, ‘head‘):
                self.head = self.get

            self.request = request
            self.args = args
            self.kwargs = kwargs

            # And continue as usual
            return self.dispatch(request, *args, **kwargs)

        # take name and docstring from class
        update_wrapper(view, cls, updated=())

        # and possible attributes set by decorators
        # like csrf_exempt from dispatch
        update_wrapper(view, cls.dispatch, assigned=())

        # We need to set these on the view function, so that breadcrumb
        # generation can pick out these bits of information from a
        # resolved URL.
        view.cls = cls
        view.initkwargs = initkwargs
        view.actions = actions
        return csrf_exempt(view)

  

函数的代码很长,我们只关注需要我们关注的代码

首先,确定as_view的函数中action的值就是我们的urls中as_view方法中的字典

action的值就是as_view方法中的字典,不信你可以实际测试一下

然后我们看下as_view这个方法的返回值

然后我们在看下as_view中的view方法

        def view(request, *args, **kwargs):
            self = cls(**initkwargs)
            # We also store the mapping of request methods to actions,
            # so that we can later set the action attribute.
            # eg. `self.action = ‘list‘` on an incoming GET request.
            self.action_map = actions

            # Bind methods to actions
            # This is the bit that‘s different to a standard view
            for method, action in actions.items():
                handler = getattr(self, action)
                setattr(self, method, handler)

            if hasattr(self, ‘get‘) and not hasattr(self, ‘head‘):
                self.head = self.get

            self.request = request
            self.args = args
            self.kwargs = kwargs

            # And continue as usual
            return self.dispatch(request, *args, **kwargs)

  

这里很重要,我们要慢慢来分析

然后在看下view这个方法的返回值

            self.request = request
            self.args = args
            self.kwargs = kwargs

            # And continue as usual
            return self.dispatch(request, *args, **kwargs)

  

我们可以看到这个函数的返回值是self.dispatch

我们注意到self.dispatch这个方法,在as_view和view均找不到,这个self是什么呢?这个self就是视图函数的类,所以我们来我们的视图函数的类中找下

明显我们自定义的AuhterModelCBV这个类没有dispatch这个方法,所以我们要去这个类的父类中查找,也就是viewsets.ModelViewSet类中查找

class ModelViewSet(mixins.CreateModelMixin,
                   mixins.RetrieveModelMixin,
                   mixins.UpdateModelMixin,
                   mixins.DestroyModelMixin,
                   mixins.ListModelMixin,
                   GenericViewSet):
    """
    A viewset that provides default `create()`, `retrieve()`, `update()`,
    `partial_update()`, `destroy()` and `list()` actions.
    """
    pass

  

这个类中也没有dispatch方法,但是这个类又继承了6个类,由于继承是从左到右继承,我们从最左边的类开始查找,最终在GeneriViewSet中找到dispatch的方法

class GenericViewSet(ViewSetMixin, generics.GenericAPIView):
    """
    The GenericViewSet class does not provide any actions by default,
    but does include the base set of generic view behavior, such as
    the `get_object` and `get_queryset` methods.
    """
    pass

  

GeneriViewSet的类中也没有dispatch方法,但是这个类有2个父类,所以我们继续往上找

最终在GenericAPIView类中找到了dispatch方法

这个类中也没有dispatch方法,我们在往他的父类中查找

最后,我们终于在APIView类中找到我们需要的dispatch方法

class APIView(View):
        def dispatch(self, request, *args, **kwargs):
        """
        `.dispatch()` is pretty much the same as Django‘s regular dispatch,
        but with extra hooks for startup, finalize, and exception handling.
        """
        self.args = args
        self.kwargs = kwargs
        request = self.initialize_request(request, *args, **kwargs)
        self.request = request
        self.headers = self.default_response_headers  # deprecate?

        try:
            self.initial(request, *args, **kwargs)

            # Get the appropriate handler method
            if request.method.lower() in self.http_method_names:
                handler = getattr(self, request.method.lower(),
                                  self.http_method_not_allowed)
            else:
                handler = self.http_method_not_allowed

            response = handler(request, *args, **kwargs)

        except Exception as exc:
            response = self.handle_exception(exc)

        self.response = self.finalize_response(request, response, *args, **kwargs)
        return self.response

  

下面在看下dispatch方法干了什么

所以执行self.create等方法就会调用我们前面已经对应的self.list。self.update等方法

至此,终极方案我们也完成了!谢谢大家的查阅!

  

原文地址:https://www.cnblogs.com/bainianminguo/p/10463893.html

时间: 2024-09-29 01:37:14

Django的rest_framework的视图之基于ModelViewSet视图源码解析的相关文章

Django的rest_framework的权限组件和频率组件源码分析

前言: Django的rest_framework一共有三大组件,分别为认证组件perform_authentication,权限组件check_throttles: 我在前面的博客中已经梳理了认证组件,不知道大家有没有看懂:在这里我把认证的组件的博客地址在贴出来,不清楚的人可以看下 局部设置认证组件的博客:https://www.cnblogs.com/bainianminguo/p/10480887.html 全局设置认证组件的博客:https://www.cnblogs.com/baini

Django中CBV和Restful API中的APIView源码分析

Django中CBV和Restful API中的APIView源码分析 python的Django框架的视图处理可以用FBV, 也可以采用CBV.首先定义一个CBV视图: from django.views import Viewfrom django.http import JsonResponseclass Book(View):    def get(self, request):        ll = [{'key':value}]        return JsonResponse

WmS详解(二)之如何理解Window和窗口的关系?基于Android7.0源码

上篇博客(WmS详解(一)之token到底是什么?基于Android7.0源码)中我们简要介绍了token的作用,这里涉及到的概念非常多,其中出现频率最高的要数Window和窗口这一对搭档了,那么我们今天就来看看到底我们该如何理解Android系统中的Window和窗口. 窗口这个概念,从不同的角度来看它的含义不一样,如果我们从WmS(WindowManagerService)的角度来看窗口,那么这个窗口并不是一个Window类,而是一个View.用户发来的消息被WmS接收之后并不能直接发给各个

SpringMVC视图机制详解[附带源码分析]

目录 前言 重要接口和类介绍 源码分析 编码自定义的ViewResolver 总结 参考资料 前言 SpringMVC是目前主流的Web MVC框架之一. 如果有同学对它不熟悉,那么请参考它的入门blog:http://www.cnblogs.com/fangjian0423/p/springMVC-introduction.html 本文将分析SpringMVC的视图这部分内容,让读者了解SpringMVC视图的设计原理. 重要接口和类介绍 1. View接口 视图基础接口,它的各种实现类是无

iOS开发- 自定义遮罩视图(引导, 功能说明)源码+解析

iOS开发- 自定义遮罩视图(引导, 功能说明)源码+解析 我们平时使用App的时候, 经常在第一次使用的时候, 会有类似"新手教程"之类的东西, 来引导我们应该如何使用这个App. 但是这个"新手教程"不同于常规的引导页(引导页指第一次打开App时候, 弹出的那种介绍视图. 他是静态的, 不需要与用户交互, 可以直接一页页翻, 或者直接跳过.)所谓的"新手教程", 就是按照App的提示, 一步步跟着完成. 那这个"新手教程"

Spring3.2 中 Bean 定义之基于 XML 配置方式的源码解析

Spring3.2 中 Bean 定义之基于 XML 配置方式的源码解析 本文简要介绍了基于 Spring 的 web project 的启动流程,详细分析了 Spring 框架将开发人员基于 XML 定义的 Bean 信息转换为 Spring 框架的 Bean Definition 对象的处理过程,向读者展示了 Spring 框架的奥妙之处,可以加深开发人员对 Spring 框架的理解. 0 评论: 秦 天杰, 软件工程师, IBM China 2013 年 9 月 02 日 内容 在 IBM

.Net Core 认证系统之基于Identity Server4 Token的JwtToken认证源码解析

介绍JwtToken认证之前,必须要掌握.Net Core认证系统的核心原理,如果你还不了解,请参考.Net Core 认证组件源码解析,且必须对jwt有基本的了解,如果不知道,请百度.最重要的是你还需要掌握identity server4的基本用法,关于identity server4因为设计到两个协议Oath2.0和openid connect协议,内容较多,不是本文重点,后续有时间我会写一片关于identity server4的源码分析.且为了保证整个系统的高度可控,我重写了整个id4,留

Django settings源码解析

Django settings源码 Django中有两个配置文件 局部配置:配置文件settings.py,即项目同名文件夹下的settings.py文件 全局配置:django内部全局的配置文件settings.py,需要导入才能看到 from django.conf import settings # 是一个对象,单例模式 from django.conf import global_settings # 真正的默认配置文件 特点: 先加载全局配置,再加载局部配置,以局部优先 源码解析 点进

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

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