クラスベースビューの利点は何ですか？

Question 1

今日、Django 1.3 alphaが出荷されていることを読みました。最も宣伝されている新機能は、クラスベースのビューの導入です。関連するドキュメント
を読みましたが、それらを使用することで得られる大きな利点™を見つけるのが難しいので、ここでそれらを理解するための助けを求めています。ドキュメントから高度な例を見てみましょう。

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))

私にとって2番目のバージョンは次のように見えます。

機能的に同等
もっと読みやすい（self.args[0]？ひどい！）
短い
DRY準拠以上

私が見逃している大きなものはありますか？なぜそれらを使用する必要がありますか？それらはドキュメントにありますか？もしそうなら、理想的なユースケースは何でしょうか？あるミックスイン便利なことは？

貢献してくれた人に感謝します！

不思議に思うかもしれない人のためのPS、私も一般的なビューに夢中になることはありませんでした：いくつかの高度な機能が必要になるとすぐに、それらは通常のビューよりも短くなりませんでした。

Question 2

クラスをサブクラス化し、特定の場合にget_context_dataなどのメソッドを改良し、残りをそのままにしておくことができます。関数ではそれを行うことはできません。

たとえば、前のビューが行うすべてのことを行う新しいビューを作成する必要があるかもしれませんが、コンテキストに追加の変数を含める必要があります。元のビューをサブクラス化し、get_context_dataメソッドをオーバーライドします。

また、テンプレートを個別のメソッドにレンダリングするために必要なステップを分離すると、コードがより明確になります。メソッドでの実行が少ないほど、理解しやすくなります。通常のビュー機能では、すべてが1つの処理装置にダンプされます。

Question 3

self.args[0]気になる場合は、次の方法があります。

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

次にself.kwargs['slug']、代わりに使用して、少し読みやすくすることができます。

Question 4

サンプルの関数とクラスは、機能が同じではありません。

クラスベースバージョンは無料でページ付けを提供し、GET以外のHTTP動詞の使用を禁止します。

これを関数に追加したい場合は、はるかに長くなります。

しかし、それは確かにもっと複雑です。

Question 5

これは私がこれを聞いた最初のものです-そして私はそれが好きです。

ここで私が見ている利点は、正直なところ、ビューがDjango全体とより一貫していることです。モデルはクラスであり、ビューもそうあるべきだといつも感じていました。私はすべてがそうであるというわけではないことを知っていますが、ビューとモデルは2つの頻繁に使用されるタイプです。

技術的なメリットは？さて、Pythonではすべてがクラス（またはオブジェクト？）です-それで本当に違いはありますか？そもそも99％の糖衣構文ではないですか？

Question 6

クラスベースのビューについて考える1つの方法は、補助輪がオフになっているDjango管理者のようなものであるため、柔軟性が大幅に向上します（ただし、理解が難しくなります）。

たとえば、管理者のリスト表示は、明らかに汎用の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/