基于类的视图有什么优势?

时间:2010-12-06 20:29:13

标签: django django-class-based-views

我今天读到Django 1.3 alpha正在发货,而最引人注目的新功能是引入了class-based views
我已经阅读了relevant documentation,但我发现很难看到使用它们可以得到的 big advantage™,所以我在这里要求一些帮助来理解它们。<登记/> 我们从文档中获取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。对于那些可能想知道的人,我也从未被通用视图所吸引:只要我需要一些高级功能,它们就不会比常规视图更短。

5 个答案:

答案 0 :(得分:48)

您可以为一个类创建子类并为特定情况细化get_context_data等方法,并将其余部分保留为原样。你不能用功能做到这一点。

例如,您可能需要创建一个新视图来执行上一个视图所做的所有操作,但您需要在上下文中包含额外的变量。对原始视图进行子类化并覆盖get_context_data方法。

此外,将模板呈现为单独的方法所需的步骤分离可以提供更清晰的代码 - 方法越少,就越容易理解。使用常规视图功能,它们都被转储到一个处理单元中。

答案 1 :(得分:16)

如果self.args[0]困扰你,可以选择:

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

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

答案 2 :(得分:10)

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

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

如果你想将它添加到你的功能中,它会更长。

但确实更复杂。

答案 3 :(得分:4)

这是我第一次听到这个 - 我喜欢它。

诚实地说,我在这里看到的优势在于它使得视图与Django整体更加一致。模特是课程,我一直认为观点也应该是。我知道不是一切,但视图和模型是两个使用频繁的类型

至于技术优势?好吧,在Python中,一切都是一个类(或对象?) - 所以真的有区别吗?首先不是99%的语法糖吗?

答案 4 :(得分:1)

考虑基于类的视图的一种方法是,它们就像一个Django管理员,训练轮子因此更加灵活(但更难以理解)。

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

class MyExampleView(ListView);
    model = ExampleModel 

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

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

使用admin,您有一个参数

list_per_page = 100

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

paginate_by = 100

实现同样的目标。同样,如果您考虑大量定制管理员,您会看到很多重叠。

这里的网站应该让你更好地了解他们的所作所为。

http://ccbv.co.uk/