一个最重要的优点是继承。在一个大型项目中，你可能会有很多类似的视图。而不是一遍又一遍地编写相同的代码，你可以简单地让你的视图从一个基础视图继承。
django还附带了一系列通用视图类，可以用来完成一些最常见的任务。例如，DetailView类用于从您的模型中传递单个对象，使用模板渲染它并返回http响应。您可以直接将其插入到您的URL conf中。

url(r'^author/(?P<pk>\d+)/$', DetailView.as_view(model=Author)),

字符串
或者您可以使用自定义功能对其进行扩展

class SpecialDetailView(DetailView):
    model = Author
    def get_context_data(self, *args, **kwargs):
        context = super(SpecialDetailView, self).get_context_data(*args, **kwargs)
        context['books'] = Book.objects.filter(popular=True)
        return context

型
现在您的模板将被传递一个用于呈现的book对象集合。
一个很好的开始是好好阅读docs（Django 4.0+）。

更新

ccbv.co.uk提供了关于类视图的全面且易于使用的信息。

当我开始使用Django时，我从来没有使用过CBV，因为它们的学习曲线和有点复杂的结构。快进两年，我只在少数地方使用FBV。我确信代码会非常简单，并且会保持简单。
CBV和多重继承沿着而来的主要好处是，我可以完全避免编写信号，帮助器方法和复制粘贴代码。特别是在应用程序做的不仅仅是基本的CRUD操作的情况下。多重继承的视图比信号和帮助器方法的代码更容易调试，特别是如果它是一个未知的代码库。
除了多重继承之外，CBV还提供了不同的方法来进行分派、检索模板、处理不同的请求类型、传递模板上下文变量、验证表单以及更多开箱即用的功能。这些使代码模块化，因此可以维护。

有些视图最好实现为CBV，而其他视图最好实现为FBV。
如果您不确定要选择哪种方法，请参阅以下图表：

的数据

两个勺子里的一些单词
提示替代Apporach -与FBV住宿

有些开发人员倾向于对大多数视图使用FBV，而只对需要子类化的视图使用CBV，这种策略也不错。

如果你想在你的Django应用中实现一个全功能的CRUD操作，基于类的视图是非常好的，同样的，使用基于函数的视图来实现也只需要很少的时间和精力。
我建议你使用基于函数的视图，当你不打算在你的网站/应用程序上实现任何CRUD意味着你的意图是简单地呈现模板。
我已经创建了一个简单的基于CRUD的应用程序，使用基于类的视图，这是活的。访问http://filtron.pythonanywhere.com/view/（将/将不会工作现在）和享受。然后你会知道它的重要性。

在大多数情况下，我一直在使用FBV，因为我看不到扩展视图的真实的机会。正如docs中所记录的那样，如果以下两个特性适合我的用例，我会考虑使用CBV。

• 与特定HTTP方法（GET、POST等）相关的代码组织可以通过单独的方法而不是条件分支来解决。
• 面向对象的技术，如mixin（多重继承），可以用来将代码分解成可重用的组件。

**基于功能的视图（FBV）**是：

• 易于使用，但
• 代码不能通过继承重用。
• 建议使用
  **基于类的视图（CBV）**是：
• 太多的学习曲线，因为它真的很复杂
• 代码可通过继承重用。
• 不推荐使用（FBV更好）