本文翻译国外作者Vitor Freitas博客文章，原文地址在这里。如有侵权，立即删除。
介绍
在django很老的版本时候，只有function-based views，但问题是是基于函数的视图太过于简单，很难去拓展,自定义它们,没法达到视图重用的地步。
为了解决这个问题，class-based views诞生了。所以，现在的django有基于函数或者基于类这两种视图。
当我们将class-based views加入到路由配置的时候。通常使用View.as_view()类方法，它返回一个函数，跟function-based views类似。
下面是源码中as_view方法的实现，相去看完整源码可以去看django完整源码：
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，你需要：
return MyView.as_view()(request)
为了让代码更清楚一点，你也可以赋值给一个变量：
view_function = MyView.as_view()
return view_function(request)
通过as_view()返回的视图函数是每个class-based view的外面一部分。调用视图函数之后，它将传递请求（request）给dispatch()方法，dispatch()方法将会根据request type (GET, POST, PUT, etc)来执行正确的方法。
Class-Based View 例子
如果你通过django.views.View基类拓展一个视图，dispatch()方法会按照逻辑自动处理HTTP方法。如果请求是一个POST，它将在视图里执行post()方法
views.py
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
urlpatterns = [
url(r'contact/$', views.ContactView.as_view(), name='contact'),
]
Function-Based View 例子
在Function-Based View中，通过表达式处理请求逻辑。
views.py
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
urlpatterns = [
url(r'contact/$', views.contact, name='contact'),
]
这两张视图主要的区别就在这。但是通用类视图（generic class-based views）就有更多故事了。
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，我一直放在书签中。
关于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然覆盖它们的属性就行了。当然，如果你想进行一个更复杂的操作，比如同时处理多个表单，那么函数视图将会更适合你。
总结
这里是我本人（并非原作者）的一些想法。一开始学django的时候，只知道基于函数的视图，这对于初学者来说是友好的。后来写的东西复杂的时候，特别是HTTP 请求不止是一开始单一的GET时，我更偏向于继承django.views.generic.View，简单覆盖方法就可以处理请求了。而对于内置的通用类视图，以及一些混合类啥的，我有些难以理解，再加上平时的开发都是前后端分离，利用django自带的模版系统的机会越来越少，所以我基本不用通用类视图。但是当你构建restful api的时候，运用到DRF框架时，里面也有类似的通用类，这个不依赖模版，真的很好用，我会在以后的章节里讲解。
