Django Class-Based Views vs. Function-Based Views

从一开始学习Django时候的Hello world的函数视图，到自带的View视图，再到restframework的APIView以及viewset。回过头来看看，好像有种从稚嫩到成熟再到老奸巨猾的感觉，代码量越来越少了，第三方库封装的越来越多，但是真正包含在其中的实现和理解我们却愈发忽视。作为一个web框架，我们在使用时应该更多在于一个完整的流程的实现过程，所以，无论是CBV还是FBV本质都是一样的

本文翻译国外作者Vitor Freitas博客，原文地址在这里。如有侵权，立即删除。

1. 介绍

在django很老的版本时候，只有function-based views，但问题是是基于函数的视图太过于简单，很难去拓展,自定义它们,没法达到视图重用的地步。
为了解决这个问题，class-based views诞生了。所以，现在的django有基于函数或者基于类这两种视图。
当我们将class-based views加入到路由配置的时候。通常使用View.as_view()类方法，它返回一个函数，跟function-based views类似。

下面是源码中as_view方法的实现，相去看完整源码可以去看django完整源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class View:
    @classonlymethod
    def as_view(cls, **initkwargs):
        """Main entry point for a request-response process."""
        for key in initkwargs:
            # ...

        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)

        # ...

        return view

所以如果你想明确调用一个class-based views，你需要： 

1
return MyView.as_view()(request)

为了让代码更清楚一点，你也可以赋值给一个变量：

1
2
view_function = MyView.as_view()
return view_function(request)

通过as_view()返回的视图函数是每个class-based view的外面一部分。调用视图函数之后，它将传递请求（request）给dispatch()方法，dispatch()方法将会根据request type (GET, POST, PUT, etc)来执行正确的方法。

2. Class-Based View 例子

如果你通过django.views.View基类拓展一个视图，dispatch()方法会按照逻辑自动处理HTTP方法。如果请求是一个POST，它将在视图里执行post()方法

views.py 

1
2
3
4
5
6
7
8
from django.views import View

class ContactView(View):
    def get(self, request):
        # Code block for GET request

    def post(self, request):
        # Code block for POST request

urls.py

1
2
3
urlpatterns = [
    url(r'contact/$', views.ContactView.as_view(), name='contact'),
]

3. Function-Based View 例子

在Function-Based View中，通过表达式处理请求逻辑。

views.py

1
2
3
4
5
def contact(request):
    if request.method == 'POST':
        # Code block for POST request
    else:
        # Code block for GET request (will also match PUT, HEAD, DELETE, etc)

urls.py

1
2
3
urlpatterns = [
    url(r'contact/$', views.contact, name='contact'),
]

这两张视图主要的区别就在这。但是通用类视图（generic class-based views）就有更多故事了。

4. Generic Class-Based Views

通用类视图在web应用中被用来解决一些常用操作，比如：创建一个新模型对象，表格处理，数据list，分页，档案视图等。
通用类视图包括在django核心包中，可以从django.views.generic导入。它们能很好地加快开发过程。下面大体列一下可用的视图：

Simple Generic Views

  • View
  • TemplateView
  • RedirectView

Detail Views

  • DetailView

List Views

  • ListView

Editing Views

  • FormView
  • CreateView
  • UpdateView
  • DeleteView

Date-Based Views

  • ArchiveIndexView
  • YearArchiveView
  • MonthArchiveView
  • WeekArchiveView
  • DayArchiveView
  • TodayArchiveView
  • DateDetailView

你可以从django官方手册上寻找更加详细的内容。

看到那么多视图时可能有点头晕，因为通用类的实现用了大量混合类（minixs）。

django文档上有个很好的资源，写着每个通用类视图的属性跟方法：Class-based generic views - flattened index，我一直放在书签中。

5. 关于django视图的见仁见智

观点1： 使用所有的通用视图！

这个观点认为.django提供常用的基础的视图让你用来减少工作量，为什么不用呢？我们可以尝试以这种观点来实践，能更快更成功地构建大量项目。

观点2:仅使用django.views.generic.View

这个观点认为,django的通用视图函数都继承与一个Generic CBV,通吃所有,想怎么自定义就怎么自定义.

观点3:避免使用通用类视图除非你想子类化这些视图

这个观点认为初学者刚开始尽量使用函数视图,因为它们更容易写跟理解,只有当你想要重用大量重用视图时才用Class-Based View

优点与缺点

优点 缺点
Function-Based Views 容易实现跟理解；流程简单；直接使用装饰器 代码难以重用；处理HTTP请求时要有分支表达式
Class-Based Views 易拓展跟代码重用；可以用混合类继承；单独用类方法处理HTTP请求；有许多内置的通用视图函数 不容易去理解；代码流程负载；父类混合类中隐藏较多代码；使用装饰器时需要额外的导入或覆盖方法

对于这两种视图的使用没有对与错,完全取决于开发状况与需求。就像文章一开始所说的，类视图不能代替函数视图。两者各有千秋。如果你想实现一个list view，那么你只需要继承ListView然覆盖它们的属性就行了。当然，如果你想进行一个更复杂的操作，比如同时处理多个表单，那么函数视图将会更适合你。

6. 总结

这里是我本人（并非原作者）的一些想法。一开始学django的时候，只知道基于函数的视图，这对于初学者来说是友好的。后来写的东西复杂的时候，特别是HTTP 请求不止是一开始单一的GET时，我更偏向于继承django.views.generic.View，简单覆盖方法就可以处理请求了。而对于内置的通用类视图，以及一些混合类啥的，我有些难以理解，再加上平时的开发都是前后端分离，利用django自带的模版系统的机会越来越少，所以我基本不用通用类视图。但是当你构建restful api的时候，运用到DRF框架时，里面也有类似的通用类，这个不依赖模版，真的很好用，我会在以后的章节里讲解。