• Django的FBV和CBV


     

    FBV

    FBV(function base views) 就是在视图里使用函数处理请求。

    在之前django的学习中,我们一直使用的是这种方式,所以不再赘述。

    CBV

    CBV(class base views) 就是在视图里使用类处理请求。

    Python是一个面向对象的编程语言,如果只用函数来开发,有很多面向对象的优点就错失了(继承、封装、多态)。所以Django在后来加入了Class-Based-View。可以让我们用类写View。这样做的优点主要下面两种:

    1. 提高了代码的复用性,可以使用面向对象的技术,比如Mixin(多继承)
    2. 可以用不同的函数针对不同的HTTP方法处理,而不是通过很多if判断,提高代码可读性

    使用class-based views

    如果我们要写一个处理GET方法的view,用函数写的话是下面这样

    from django.http import HttpResponse
      
    def my_view(request):
         if request.method == 'GET':
                return HttpResponse('OK')

    如果用class-based view写的话,就是下面这样

    复制代码
    from django.http import HttpResponse
    from django.views import View
      
    class MyView(View):
    
          def get(self, request):
                return HttpResponse('OK')
    复制代码

    Django的url是将一个请求分配给可调用的函数的,而不是一个class。针对这个问题,class-based view提供了一个as_view()静态方法(也就是类方法),调用这个方法,会创建一个类的实例,然后通过实例调用dispatch()方法,dispatch()方法会根据request的method的不同调用相应的方法来处理request(如get() , post()等)。到这里,这些方法和function-based view差不多了,要接收request,得到一个response返回。如果方法没有定义,会抛出HttpResponseNotAllowed异常。

    在url中,就这么写:

    复制代码
    # urls.py
    from django.conf.urls import url
    from myapp.views import MyView
      
    urlpatterns = [
         url(r'^index/$', MyView.as_view()),
    ]
    复制代码

    我们可以看看as_view这个方法的源码

    复制代码
    @classonlymethod
        def as_view(cls, **initkwargs):
            """
            Main entry point for a request-response process.
            """
            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. as_view "
                                    "only accepts arguments that are already "
                                    "attributes of the class." % (cls.__name__, key))
    
            def view(request, *args, **kwargs):
                self = cls(**initkwargs)
                if hasattr(self, 'get') and not hasattr(self, 'head'):
                    self.head = self.get
                self.request = request
                self.args = args
                self.kwargs = kwargs
                return self.dispatch(request, *args, **kwargs)
            view.view_class = cls
            view.view_initkwargs = initkwargs
    
            # 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=())
            return view
    复制代码

    可以看到as_view最终的执行结果就是返回了一个view函数,而在url中其实我们就是在调用这个函数,这个函数先是实例化出了一个View类的对象,最后返回的是这个对象的dispatch方法的执行结果

    那么这个dispatche方法又干了什么呢

    复制代码
        def dispatch(self, request, *args, **kwargs):
            # Try to dispatch to the right method; if a method doesn't exist,
            # defer to the error handler. Also defer to the error handler if the
            # request method isn't on the approved list.
            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
            return handler(request, *args, **kwargs)
    复制代码

    这个方法其实就是判断我们的请求方法,并根据请求方法执行相应的方法对应的函数

    类的属性可以通过两种方法设置,第一种是常见的Python的方法,可以被子类覆盖

    复制代码
    from django.http import HttpResponse
    from django.views import View
      
    class GreetingView(View):
        name = "yuan"
        def get(self, request):
             return HttpResponse(self.name)
      
    # You can override that in a subclass
      
    class MorningGreetingView(GreetingView):
        name= "alex"
    复制代码

    第二种方法,你也可以在url中指定类的属性:

    在url中设置类的属性Python

    urlpatterns = [
       url(r'^index/$', GreetingView.as_view(name="egon")),
    ]

    使用Mixin

    我觉得要理解django的class-based-view(以下简称cbv),首先要明白django引入cbv的目的是什么。在django1.3之前,generic view也就是所谓的通用视图,使用的是function-based-view(fbv),亦即基于函数的视图。有人认为fbv比cbv更pythonic,窃以为不然。python的一大重要的特性就是面向对象。而cbv更能体现python的面向对象。cbv是通过class的方式来实现视图方法的。class相对于function,更能利用多态的特定,因此更容易从宏观层面上将项目内的比较通用的功能抽象出来。关于多态,不多解释,有兴趣的同学自己Google。总之可以理解为一个东西具有多种形态(的特性)。cbv的实现原理通过看django的源码就很容易明白,大体就是由url路由到这个cbv之后,通过cbv内部的dispatch方法进行分发,将get请求分发给cbv.get方法处理,将post请求分发给cbv.post方法处理,其他方法类似。怎么利用多态呢?cbv里引入了mixin的概念。Mixin就是写好了的一些基础类,然后通过不同的Mixin组合成为最终想要的类。

    所以,理解cbv的基础是,理解Mixin。Django中使用Mixin来重用代码,一个View Class可以继承多个Mixin,但是只能继承一个View(包括View的子类),推荐把View写在最右边,多个Mixin写在左边。

    关于csrf_token的装饰器

    我们知道当我们向django发送post请求时,有一个中间件会检验csrf_token,如果我们不想使用它可以将它注释,同样我们也可以通过装饰器来避免发送POST请求时被服务器拒绝

    复制代码
    from django.shortcuts import render, HttpResponse
    from django.views import View
    # Create your views here.
    from django.views.decorators.csrf import csrf_exempt, csrf_protect
    from django.utils.decorators import method_decorator
    
    
    @csrf_exempt  # 避免csrf验证
    def foo(request):
        return HttpResponse("foo")
    
    # 方式1
    # @method_decorator(csrf_exempt, name="dispatch")
    class IndexView(View):
        # 方式2
        @method_decorator(csrf_exempt)
        def dispatch(self, request, *args, **kwargs):
            print("hello world")
            # 执行父类的dispatch方法
            res = super(IndexView, self).dispatch(request, *args, **kwargs)
            return res
    
        def get(self, request, *args, **kwargs):
            return HttpResponse("index")
        
        def post(self, request, *args, **kwargs):
            return HttpResponse("post index")
    
        def delete(self, request):
            return HttpResponse("delete index")    
    复制代码

    可以看到FBV和CBV的形式都可以通过装饰器的形式来实现,还有一个csrf_protect是可以在中间件被注释时也可以进行验证

  • 相关阅读:
    UE4中集成ProtoBuf
    QT之打印 QPrinter
    qt界面嵌入外部进程界面
    QAxWidget 妙用
    UE4嵌入Qt5 三维可视化案例
    QSS入门(一)
    Docker与k8s的恩怨情仇(四)-云原生时代的闭源落幕
    成品软件二次开发排第三,低代码的应用场景有哪些?
    React 并发功能体验-前端的并发模式已经到来。
    Docker与k8s的恩怨情仇(三)—后浪Docker来势汹汹
  • 原文地址:https://www.cnblogs.com/xyhh/p/10861218.html
Copyright © 2020-2023  润新知