基于类的视图有什么优势？答案

【问题标题】：What is the advantage of Class-Based views?基于类的视图有什么优势？
【发布时间】：2010-12-06 20:29:13
【问题描述】：

我今天看到 Django 1.3 alpha 即将发布，最受吹捧的新功能是引入了class-based views。
我已经阅读了relevant documentation，但我发现我很难看到使用它们可以获得的巨大优势™，所以我在这里寻求一些帮助来理解它们。
让我们从文档中获取advanced example。

urls.py

>

from books.views import PublisherBookListView

urlpatterns = patterns('',
    (r'^books/(\w+)/$', PublisherBookListView.as_view()),
)

views.py

>

from django.shortcuts import get_object_or_404
from django.views.generic import ListView
from books.models import Book, Publisher

class PublisherBookListView(ListView):

    context_object_name = "book_list"
    template_name = "books/books_by_publisher.html",

    def get_queryset(self):
        self.publisher = get_object_or_404(Publisher, name__iexact=self.args[0])
        return Book.objects.filter(publisher=self.publisher)

    def get_context_data(self, **kwargs):
        # Call the base implementation first to get a context
        context = super(PublisherBookListView, self).get_context_data(**kwargs)
        # Add in the publisher
        context['publisher'] = self.publisher
        return context

现在让我们将其与我在 5 分钟内为这个问题制作的“普通旧视图”解决方案进行比较（对于您可能在其中发现的任何错误，我深表歉意）。

urls.py

>

urlpatterns = patterns('books.views',
    url(r'^books/(\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

views.py

>

from django.shortcuts import get_object_or_404
from books.models import Book, Publisher

def publisher_books_list(request, publisher_name):
    publisher = get_object_or_404(Publisher, name__iexact=publisher_name)
    book_list = Book.objects.filter(publisher=publisher)

    return render_to_response('books/books_by_publisher.html', {
        "book_list": book_list,
        "publisher": publisher,
    }, context_instance=RequestContext(request))

第二个版本在我看来：

功能等效
可读性更强（self.args[0]？糟透了！）
更短
不低于 DRY 标准

我错过了什么重要的东西吗？我为什么要使用它们？那些在文档上吗？如果是这样，那么理想的用例是什么？ mixins 有用吗？

提前感谢任何做出贡献的人！

P.S.对于那些可能想知道的人，我也从未被通用视图所吸引：只要我需要一些高级功能，它们就不会比普通视图短。

【问题讨论】：

是的，我也没有看到很大的优势。希望看到一个重要的答案。
完全同意。我对 self.args[0] 或 self.kwargs['slug'] 尤其反感。现在为 url 参数提供默认值也变得更加困难，例如：def publisher_books_list(request, publisher_name='Herbert')

标签： django django-class-based-views

【解决方案1】：

您可以对一个类进行子类化，并针对特定情况优化 get_context_data 等方法，其余部分保持原样。函数无法做到这一点。

例如，您可能需要创建一个新视图来完成前一个视图所做的一切，但您需要在上下文中包含额外的变量。子类化原始视图并覆盖 get_context_data 方法。

此外，将呈现模板所需的步骤分离到单独的方法中可以促进代码更清晰 - 方法中完成的越少，就越容易理解。使用常规视图函数，所有这些都被转储到一个处理单元中。

【讨论】：

是的，我可以看到这个。在尝试决定是否应该使用 RESTful、拥有完整站点或移动站点时，它可以轻松覆盖和频繁混合。有了这个，可以在导出功能时尽可能推迟该决定。 Pylons 中的 Webware 模块有这个，它非常有用。也就是说，通过覆盖 __call__() 方法，Django 长期以来一直可以使用基于类的视图。
接受答案，因为它提供了一个很好的观点......但仍然觉得没有必要使用它们，因为我很少有这样的问题需要解决。谢谢！

【解决方案2】：

如果self.args[0] 困扰您，替代方案是：

urlpatterns = patterns('books.views',
    url(r'^books/(?P<slug>\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

然后您可以改用self.kwargs['slug']，使其更具可读性。

【讨论】：

【解决方案3】：

您的示例函数和类在功能上不相等。

基于类的版本免费提供分页，并禁止使用除 GET 之外的其他 HTTP 动词。

如果你想将它添加到你的函数中，它会更长。

但它确实更复杂。

【讨论】：

+1 用于指出差异，但我个人认为 require_GET 和 django-pagination 使用起来很简单，简洁，明确等，我更喜欢它们而不是 cbvs at (almost :)) all次。

【解决方案4】：

这是我第一次听到这个——我很喜欢。

老实说，我在这里看到的优势是它使视图与 Django 整体更加一致。模型是类，我一直认为视图也应该如此。我不知道一切都是，但视图和模型是两种使用频率很高的类型。

至于技术优势？好吧，在 Python 中，一切都是类（或对象？）——那么真的有区别吗？首先不是 99% 的语法糖吗？

【讨论】：

我会说一致性允许更多的代码重用。如果您的观点符合某些模式，他们基本上会减少很多样板。例如，使用基于类的视图生成基于模型的表单非常快。如果它需要几个额外的字段，它开始变得有点棘手。如果您需要基于三个模型和两个额外字段的表单，它们可能根本不会为您节省太多精力。

【解决方案5】：

考虑基于类的视图的一种方式是，它们就像一个没有训练轮的 Django 管理员，因此更加灵活（但更难理解）。

例如，admin 中的列表显示显然是基于通用 ListView。最简单的列表视图，您只需定义一个模型或查询集。

class MyExampleView(ListView);
    model = ExampleModel

您需要提供自己的模板，但它基本上与最基本的 ModelAdmin 相同。模型管理中的 list_display 属性将告诉它要显示哪些字段，而在 ListView 中，您将在模板中执行此操作。

class SpeciesAdmin(admin.ModelAdmin):
    list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)

使用管理员你有一个参数

list_per_page = 100

它定义了每页有多少对象。列表视图有

paginate_by = 100

达到同样的效果。同样，如果您考虑大量定制管理员，您会看到很多重叠。

这里的这个网站应该让您更好地了解他们的工作。

http://ccbv.co.uk/

【讨论】：