python3-开发进阶Django-CBV和FBV及CBV的源码分析

一、CBV和FBV

全称应该是class base views 和function base views
理解起来应该就是基于类的视图函数和基于函数的视图函数

FBV

应该是我目前最常用的一种方式了，就是给每一个views里的功能添加自己专用的方法。例如如果要对网页进行get访问，然后通过获得request中post方式传递的form表单获取数据。

from django.http import HttpResponse

def login(request):

    if request.method == 'GET':

        return HttpResponse('OK1')

    if request.method =="POST":

         return HttpResponse('OK2')
　　 。。。

CBV

但是这种方法，看起来有点臃肿，查看代码的时候不容易看清楚你的post请求get请求是在哪里处理的，所以就有了CBV的处理方法。

在views文件中：

from django.views import View

class LoginView(View):

    def get(self,request):

        return render(request,"login.html")

    def post(self,request):

        user=request.POST.get('user')

        pwd=request.POST.get('pwd'))

        if Turn:  #假使验证成立

            return HttpResponse("OK3")

在CBV的使用中，需要调用父类View，它会在源码里解释这个CBV的应用范围，以及运作原理。

在urls文件中：

from app01 import views

urlpatterns = [

    url(r'^admin/', admin.site.urls),

    url(r'^login/$',views.LoginView.as_view())，
　　# url(r'^login/$',views.login)

]

综上所述：
我们可以知道设置一个CBV方法，要做的就是，在views里创建一个类，这个类的父类一定得是View，而且在urls设置的时候，url指向的不再是一个函数名，而是你定义的类的.as_view()方法

运行起来之后，会发现当向login.html这个url发送get请求的时候，成功，发送post请求的时候，也成功，并且有相应的返回值。

二、原理

翻看源码，实现以上功能的核心，其实都在那个被继承的父类View里：

class View(object):

    """

    Intentionally simple parent class for all views. Only implements

    dispatch-by-method and simple sanity checking.

    """

    http_method_names = ['get', 'post', 'put', 'patch', 'delete', 'head', 'options', 'trace']

    def __init__(self, **kwargs):

        """

        Constructor. Called in the URLconf; can contain helpful extra

        keyword arguments, and other things.

        """

        # Go through keyword arguments, and either save their values to our

        # instance, or raise an error.

        for key, value in six.iteritems(kwargs):

            setattr(self, key, value)

    @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

    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)

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

        logger.warning(

            'Method Not Allowed (%s): %s', request.method, request.path,

            extra={'status_code': 405, 'request': request}

        )

        return http.HttpResponseNotAllowed(self._allowed_methods())

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

        """

        Handles responding to requests for the OPTIONS HTTP verb.

        """

        response = http.HttpResponse()

        response['Allow'] = ', '.join(self._allowed_methods())

        response['Content-Length'] = ''

        return response

    def _allowed_methods(self):

        return [m.upper() for m in self.http_method_names if hasattr(self, m)]

从源码中我们可以看到。这个CBV的核心类，是为了处理各种请求服务的。其中有一个list来存放这些请求，并且指向他们应该实现的函数功能。
再补充一点，在CBV创建类方法的时候，一定要携带一个request参数。而这个参数里面就携带了request.method.lower()，通过反射，CBV函数自然能处理这些method对应的请求。

三、逻辑过程

看源码的准则就看，看自己看的懂得代码，应为源码的有些高深的设置，我们先阶段还不需要去了解.

首先，不管cbv还是fbv，在url中都是用户访问请求，才回去执行相应的视图函数,

cbv在启动项目的时候，已经在LoginView中执行一段骚操作的得到一个函数名，我们现在就来看看：

首先我们要明确的一点就是一个类.属性或方法，首先在自己那找，找不到继承的父类找。所以不能直接点。as_view，

先去类LoginView中找看看有，有没有方法：

点开View，我们找到as_view方法，发现是类方法，

前面过程做了什么我们不管，返回值只是返回一个view，调用view函数，我们去看view函数，

view函数最后返回self.dispacth,这里要注意！！！这个self.dispacth，self是谁，self我们看代码发现是LoginView类，

还是那个准则，调用属性方法，现在自己那边找，没有再找父类。

因为LoginView中没有dispath这方法，所以还是执行的父类的dispath方法：

注意点：还是在调用某个方法时，我们一定要确定是谁去调用这个方法！找方法一定先找自己的，没有再去父类找！

四、思考自定义的dispatch

既然在上面我们查看源码的时候已经发现，导向专门的method操作的函数是dispatch，而且每个CBV类的父类都是View，那我能不能在这个dispatch里面做一些定制化操作，

继承父类的dispatch

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

    obj=super(login,self).dispatch(request, *args, **kwargs)

    return obj

    # 由于父类的dispatch最后返回了一个handle，也就是一个返回值，所以在继承的时候也应该提供一个返回值

装饰化这个dispatch

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

    print('123‘)

    obj=super(login,self).dispatch(request, *args, **kwargs)

    print('')

    return obj

反馈的效果：

不管是什么方法请求，都必须要打印123，456

总的来说，这个只是一个简单的示范处理，如果需要对过来的请求做更多的润色，还需要在这个继承动作前后做更多工作。需要知道的是，他和装饰器略微不懂，那就是他可以共享这个dispatch的request，并且对他进行工作

巴特西

python3-开发进阶Django-CBV和FBV及CBV的源码分析

一、CBV和FBV

FBV

CBV

二、原理

三、逻辑过程

四、思考自定义的dispatch

最新文章

热门文章