首页 文章

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

提问于
浏览 次
77

我今天读到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标准

有什么东西我不见了吗？我为什么要用它们？文档上有那些？如果是这样，那么理想的用例是什么？ mixin有用吗？

提前感谢任何贡献者！

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

django django-class-based-views

5 回答

  • 4

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

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

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

    回复于
  • 47

    考虑基于类的视图的一种方法是，它们就像一个Django管理员，训练轮关闭，因此更灵活（但更难理解） .

    例如，管理员中的列表显示显然基于通用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/

    回复于
  • 1

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

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

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

    但它确实更复杂 .

    回复于
  • 16

    如果 self.args[0] 困扰你，另一种选择是：

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

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

    回复于
  • 10

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

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

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

    回复于

相关问题