CBV流程

django CBV 源码分析

FBV和CBV

FBV（function base views） 就是在视图里使用函数处理请求。 
在之前django的学习中，我们一直使用的是这种方式，所以不再赘述。

CBV（class base views） 就是在视图里使用类处理请求。 
Python是一个面向对象的编程语言，如果只用函数来开发，有很多面向对象的优点就错失了（继承、封装、多态）。所以Django在后来加入了Class-Based-View。可以让我们用类写View。这样做的优点主要下面两种：

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

CBV 源码分析

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)]

class View(object)

在url中会执行一个叫做as_view的方法，这个方法在加载url时候会执行   得到一个返回值view 是一个函数 供url调用

那么view 究竟做了什么呢？

当url执行view时候，会把下边这句代码作为返回值

self.dispatch(request, *args, **kwargs)

所view 会调用当前调用类的dispatch

CBV 的api接口 dispatch

在执行dispatch的时候，如果views中的视图类 自定义了dispatch那么将优先执行自定义的dispatch  由此可在请求处理前增加一些处理，

然后再用super方法去调用父类的dispatch ，当然也可以自己把父类的功能全部写在自己的自定义里边。

那么就说下父类的dispatch做了什么功能呢

简单的说-----分发

复杂的说-----找到这次请求对应的类型，然后用反射把这个方法取到，然后作为自己的返回值，返回给调用这个方法的view

因此我们得到一个结论，两种方式的最终结果都是把要执行的视图函数放在url的第二个参数位置  不过CBV在请求的前后给我们提供了丰富的扩展空间