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

StackOverflow https://stackoverflow.com/questions/4370650

  •  09-10-2019
  •  | 
  •  

質問

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

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]？最悪！）
  • 短い
  • それほど乾燥していない

私が足りない何かがありますか？なぜそれらを使用する必要があるのですか？それらはドキュメントにありますか？もしそうなら、理想的なユースケースは何でしょうか？は ミキシン それは役に立ちますか？

貢献してくれる人によろしくお願いします！

詩 疑問に思うかもしれない人にとって、私は一般的な見解にも魅了されませんでした。高度な機能が必要になるとすぐに、通常のビューよりも短くなりませんでした。

役に立ちましたか？

解決

クラスをサブクラス化して、特定のケースのget_context_dataなどの方法を改良し、残りをそのまま残します。関数でそれを行うことはできません。

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

また、テンプレートを個別のメソッドにレンダリングするために必要な手順を分離すると、より明確なコードが促進されます。メソッドで完了するほど、理解しやすくなります。通常のビュー関数を使用すると、すべて1つの処理ユニットに投棄されます。

他のヒント

もしも self.args[0] あなたを悩ませている、代替案は次のとおりです。

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

その後、使用できます self.kwargs['slug'] 代わりに、少し読みやすくします。

機能とクラスの例は、機能が等しくありません。

クラスベースのバージョンは、無料でページネーションを提供し、取得よりも他のHTTP動詞の使用を禁止します。

これを機能に追加する場合は、はるかに長くなります。

しかし、実際、それはより複雑です。

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

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

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

クラスベースのビューについて考える1つの方法は、トレーニングホイールをオフにしているため、より柔軟性がある（ただし、理解するのが難しい）ジャンゴ管理者のようなものであるということです。

たとえば、管理者のリストディスプレイは、明らかに汎用リストビューに基づいています。最も単純なリストビューは、モデルまたはQuerySetのみを定義します。 

class MyExampleView(ListView);
    model = ExampleModel

独自のテンプレートを提供する必要がありますが、基本的に最も基本的なモデルADMINと同じです。モデル管理者の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/

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top