クラスベースビューはビューを実装するもう一つの手段で、関数の代わりに Python のオブジェクトとしてビューを定義します。クラスベースビューは関数ベースのビューを完全に置き換えるものではありませんが、関数ベースのビューと比較して、以下のような違いと利点があります。
\n特定の HTTP メソッド (GET 、 POST など) に関連するコードの集まりを、条件分岐を使ってかき分けるのではなく、それぞれに独立したメソッドを割り当てることができる。
ミックスイン (多重継承) などのオブジェクト指向のテクニックを使って、コードを再利用可能なコンポーネントに分解できる。
まず初めに存在したのは、ビュー関数の規約だけでした。Django は、定義された関数に HttpRequest を渡して、HttpResponse が返ってくることを期待していました。Django が提供する機能はこの範囲まででした。
早い内に、ビューの開発には共通のイディオムやパターンが存在することが認識されるようになりました。こうしたパターンを抽象化し、共通ケースに当てはまるようなビューの開発を楽にするために導入されたのが、関数ベースのジェネリックビューでした。
\n関数ベースのジェネリックビューの問題点は、単純なケースを十分にカバーしていたものの、設定オプションを超えて拡張したりカスタマイズしたりする方法がなく、多くの実世界のアプリケーションでの有用性が制限されていたことです。
\nクラスベースのジェネリックビューは関数ベースのジェネリックビューと同様に、ビューの開発を楽にすることを目的に作成されました。しかし、ミックスインを使用するなどの実装方法の工夫により、ツールキットを提供することができ、結果として、関数ベースのジェネリックビューに比べて、より拡張性が高く、柔軟なものにすることができました。
\nもしあなたが昔、関数ベースのジェネリックビューを使用しようとして、物足りないと思ったなら、クラスベースのジェネリックビューを、関数ベースからクラスベースにしただけのようなものとは考えないでください。むしろ、ジェネリックビューが解決しようとしていた、元々あった問題を解くための新しいアプローチとしてとらえてください。
\nDjango がクラスベースのジェネリックビューを構築するために使用する基底クラスと mixin のツールキットは、最大限の柔軟性を求めて構築されており、デフォルトのメソッド実装や、最も単純なユースケースでは気にすることのない属性の形で多くのフックを持っています。たとえば、form_class のクラスベースの属性に制限する代わりに、実装では get_form メソッドを使用しており、 get_form_class メソッドを呼び出します。これにより、どのフォームを使用するかを指定するために、属性から完全に動的で呼び出し可能なフックまで、いくつかのオプションが用意されています。これらのオプションは、単純な状況では中途半端な複雑さを追加しているように見えますが、これがなければ、より高度なデザインは制限されてしまいます。
中核となる機能として、クラスベースのビューでは、HTTP リクエストのメソッドに応じてクラスインスタンスの異なるメソッドを呼び出させることができるため、1つのビュー関数の内部で条件分岐を使わずにすみます。
\nそのため、ビュー関数の場合に HTTP GET をハンドリングするコードが次のようになるとすると、
from django.http import HttpResponse\n\n\ndef my_view(request):\n if request.method == "GET":\n # <view logic>\n return HttpResponse("result")\nクラスベースのビューでは以下のようになります。
\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass MyView(View):\n def get(self, request):\n # <view logic>\n return HttpResponse("result")\nDjangoのURLリゾルバは、クラスではなく、コール可能な関数にリクエストと関連する引数を送信することを期待しているため、クラスベースのビューには、関連するパターンに一致するURLに対するリクエストが到着したときに呼び出すことができる関数を返す as_view() クラスメソッドがあります。この関数はクラスのインスタンスを作成し、setup() を呼び出してその属性を初期化し、次にその dispatch() メソッドを呼び出します。dispatch はリクエストを調べて、それが GET、POST などであるかを判断し、定義されている場合は一致するメソッドにリクエストを中継し、定義されていない場合は HttpResponseNotAllowed を発生させます:
# urls.py\nfrom django.urls import path\nfrom myapp.views import MyView\n\nurlpatterns = [\n path("about/", MyView.as_view()),\n]\nメソッドが関数ベースのビューが返すもの、つまり何らかの形の HttpResponse と同等のものしか返せないなら意味はありません。これが意味するのは、 http ショートカット や TemplateResponse オブジェクトはクラスベースのビューの内部でも使えるということです。
最小限のクラスベースのビューでは、ジョブを実行するのにどんなクラス属性も必要としませんが、クラスベースの設計をする場合にはクラス属性が役に立つことが多いです。クラス属性のカスタマイズと設定を行うには2つの方法があります。
\n第1の方法は、通常の Python のサブクラス化を行い、サブクラス上で属性やメソッドを上書きするという方法です。たとえば、次のように親クラスが greeting という属性を持っていたとすると、
from django.http import HttpResponse\nfrom django.views import View\n\n\nclass GreetingView(View):\n greeting = "Good Day"\n\n def get(self, request):\n return HttpResponse(self.greeting)\nサブクラスでは次のように属性を上書きできます。
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nもう一つの方法は、URLconf 内での as_view() の呼び出し時に、クラス属性をキーワード引数として指定する方法です。
urlpatterns = [\n path("about/", GreetingView.as_view(greeting="G'day")),\n]\nミックスインは、複数の親クラスのメソッドや属性を混合することができる多重継承の形式の1つです。
\nたとえば、ジェネリッククラスベースのビューには、 TemplateResponseMixin と呼ばれるミックスインがあり、その主な目的はメソッド render_to_response() を定義することです。 View 基底クラスの動作と組み合わせると、適切なマッチングメソッド（ View クラス基底クラスで定義されている動作）にリクエストをディスパッチする TemplateView メソッドクラスとなり、 template_name 属性を使用してTemplateResponseオブジェクト（TemplateResponseMixin で定義されている動作）を返す render_to_response() メソッドを持っています。
ミックスインは複数のクラスにまたがってコードを再利用するためのよい方法ですが、それなりの代償も伴います。コードがミックスインの中に散らばると、子クラスを読んだときそのクラスが何をしているのかを正確に知ることが難しくなり、深い継承ツリーを持つクラスをサブクラス化している場合、どのミックスインのどのメソッドをオーバーライドすればいいのかわからなくなります。
\nまた、1つの汎用ビューからしか継承できないことにも注意してください - つまり、親クラスは1つだけ View を継承することができ、残りのクラスは（もしあれば）ミックスインでなければなりません。View を継承している複数のクラスから継承しようとすると - たとえば、リストの先頭にあるフォームを使用して ProcessFormView と ListView を組み合わせようとすると - 期待通りには動作しません。
フォームを扱う基本の関数ベースのビューは、次のようなコードになります。
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import MyForm\n\n\ndef myview(request):\n if request.method == "POST":\n form = MyForm(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n else:\n form = MyForm(initial={"key": "value"})\n\n return render(request, "form_template.html", {"form": form})\n同等のクラスベースのビューは、次のようになるでしょう。
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\nfrom django.views import View\n\nfrom .forms import MyForm\n\n\nclass MyFormView(View):\n form_class = MyForm\n initial = {"key": "value"}\n template_name = "form_template.html"\n\n def get(self, request, *args, **kwargs):\n form = self.form_class(initial=self.initial)\n return render(request, self.template_name, {"form": form})\n\n def post(self, request, *args, **kwargs):\n form = self.form_class(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n\n return render(request, self.template_name, {"form": form})\nこれは最低限のケースですが、クラス属性を上書きするなどの方法でこのビューをカスタマイズする手段が用意されていることがわかります。たとえば、 form_class を URLconf 設定で指定したり、サブクラス化して1つ以上のメソッドを上書きしたりすることもできます。
クラスベースのビューを拡張する方法は、ミックスインの使用にとどまりません。デコレータも使用できます。クラスベースのビューは関数ではないので、as_view() を使用した場合とサブクラスを作成した場合では、デコレータは違った動作をします。
クラスベースのビューをデコレーションするには、 as_view() メソッドの結果をデコレートします。これが最も簡単にできる場所は、ビューをデプロイする URLconf の中です。
from django.contrib.auth.decorators import login_required, permission_required\nfrom django.views.generic import TemplateView\n\nfrom .views import VoteView\n\nurlpatterns = [\n path("about/", login_required(TemplateView.as_view(template_name="secret.html"))),\n path("vote/", permission_required("polls.can_vote")(VoteView.as_view())),\n]\nこのアプローチではデコレータはインスタンスごとに適用されます。もしあるビューのすべてのインスタンスをデコレーションしたいばあいは、別のアプローチを取る必要があります。
\nクラスベースのビューのすべてのインスタンスをデコレーションするには、クラスの定義自体をデコレーションする必要があります。そのためには、クラスの dispatch() メソッドにデコレータを付けます。
クラス上のメソッドはスタンドアロンの関数と完全に同じではないため、関数デコレータを単純にそのままメソッドに適用することはできません。適用前にメソッドデコレータに変換する必要があります。method_decorator デコレータを使えば、関数デコレータをメソッドデコレータに変換し、インスタンスのメソッドのデコレーションに使えるようにできます。たとえば、次のように使用します。
from django.contrib.auth.decorators import login_required\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import TemplateView\n\n\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n @method_decorator(login_required)\n def dispatch(self, *args, **kwargs):\n return super().dispatch(*args, **kwargs)\nあるいは、より簡潔に、クラスを代わりにデコレートして、デコレーション対象のメソッド名をキーワード引数 name に渡すという方法もあります。
@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n共通のデコレータ群が複数の場所で呼ばれる場合には、デコレータのリストまたはタプルを定義して、これを method_decorator() を複数回呼ぶ代わりに使用できます。以下の2つのクラスは同じになります。
decorators = [never_cache, login_required]\n\n\n@method_decorator(decorators, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n\n@method_decorator(never_cache, name="dispatch")\n@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\nデコレータは、デコレータに渡された順番でリクエストを処理します。上の例では、never_cache() が login_required() の前にリクエストを処理します。
この例では、 ProtectedView のすべてのインスタンスがログイン保護されます。これらの例では login_required を使っていますが、 LoginRequiredMixin を使っても同じことができます。