类视图的使用

前言

对于类视图和函数视图，在我初学django的时，有过这样的迷思：自己定义的类视图似乎和函数视图没有太大的区别，无非就是判断请求方式的时候，CBV用函数，FBV用if...else...。而如果上了框架提供的通用类视图，代码风格似乎过于抽象，且不灵活，无法完全替代函数视图。今天，就以刚刚用函数视图完成的项目为例，尝试将所有函数视图转为类视图，看看过程中有什么新的感悟。

通用类视图里的方法

添加额外的上下文：

def get_context_data(self, **kwargs):
    # Call the base implementation first to get a context
    context = super().get_context_data(**kwargs)
    # Add in a QuerySet of all the books
    context["book_list"] = Book.objects.all()
    return context

根据url内传来的query参数来动态查询

这项工作的关键部分是当基于类的视图被调用的时候，各种常用的东西被存储在 self 上，而且请求 (self.request) 根据 URLconf 抓取位置(self.args) 和基于名称 (self.kwargs) 的参数。

def get_queryset(self):
    self.publisher = get_object_or_404(Publisher, name=self.kwargs["publisher"])
    return Book.objects.filter(publisher=self.publisher)

执行额外的任务

class AuthorDetailView(DetailView):
    queryset = Author.objects.all()

    def get_object(self):
        obj = super().get_object()
        # Record the last accessed date
        obj.last_accessed = timezone.now()
        obj.save()
        return obj

通用类视图到底为开发者默认做了哪些事

django框架内置的通用类视图之所以能少些很多代码，很明显是它有一些默认行为。那么这里就记录一下各种常见内置视图的默认行为。

FormView

class ContactFormView(FormView):
    template_name = "contact.html"
    form_class = ContactForm
    success_url = "/thanks/"

    def form_valid(self, form):
        # This method is called when valid form data has been POSTed.
        # It should return an HttpResponse.
        form.send_email()
        return super().form_valid(form)

表单视图的一般行为是判断请求方式，如果是post，就检验字段有效性，且把错误返回给浏览器，成功则重定向；如果是get就返回待填写的表单。

所以，FormView就是通过暴露一些简单的配置给开发者，比如template_name，其他行为会自动完成。如果有特殊需求，重写get或post方法。form_valid是执行表单验证之后的程序。

form_valid函数是一定要重写的，这也说明django文档里一般都是最小实现形式，不能减少。

总结

• 类视图完全可以替代函数视图。
• 优先用内置的通用类视图，首先确认任务类型，如果是展示类，就考虑ListView、DetailVIew；如果是修改类，就是CreateView、UpdateView、DeleteView。
• 修改类的通用视图，注意表单相关项。运用上面提到的三个函数，可以实现较复杂的需求。
• 如果不方便，也可以不用内置视图，而采用根据请求方式划分方法，比如get请求。
• 类视图在采用了内置类的写法后，代码会变少；但更重要的意义是，增加了代码重用的可能性。比如，另外一个views.py可以继承过来。