ビューはリクエストを受けてレスポンスを返す callable です。これは単なる関数以上のものになる可能性があり、Django ではビューとして使用できるいくつかのクラスの例を提供しています。これらのクラスは、継承やミックスインを利用してビューを構造化し、コードを再利用することを可能にします。後ほど説明するタスクのための汎用的なビューもありますが、あなたのユースケースに合った再利用可能なビューの構造を独自に設計したいと思うかもしれません。詳細については、クラスベースのビューの リファレンスドキュメント を参照してくださ
\n\nDjango には、幅広いアプリケーションに適した基本的なビュークラスが用意されています。すべてのビューは View クラスを継承しており、ビューを URL にリンクさせたり、HTTP メソッドのディスパッチやその他の共通機能を処理します。RedirectView はHTTPリダイレクトを提供し、TemplateView は基底クラスを拡張してテンプレートもレンダリングできるようにしています。
汎用ビューを使用する最も直接的な方法は、URLconfで直接作成することです。クラスベースのビューでいくつかの属性のみを変更する場合は、それらを as_view() メソッド呼び出し自体に渡すことができます:
from django.urls import path\nfrom django.views.generic import TemplateView\n\nurlpatterns = [\n path('about/', TemplateView.as_view(template_name="about.html")),\n]\nas_view() に渡されたすべての引数は、クラスで設定された属性を上書きします。次の例では TemplateView の template_name を設定しています。同様の上書きのパターンは、RedirectView の url 属性でも使えます。
2つ目の、より強力な汎用ビューの使用方法は、既存のビューを継承し、サブクラス内の属性（ template_name``など）やメソッド（ ``get_context_data``など）をオーバーライドして、新しい値やメソッドを提供することです。例えば、``about.html. というテンプレートを表示するだけのビューを考えてみましょう。Django にはこれを行うための汎用ビュー、TemplateView があるので、それをサブクラス化してテンプレート名をオーバーライドすることができます:
# some_app/views.py\nfrom django.views.generic import TemplateView\n\nclass AboutView(TemplateView):\n template_name = "about.html"\n次に、この新しいビューをURLconfに追加する必要があります。TemplateView は関数ではなくクラスなので、代わりに as_view() クラスメソッドを URL に指定します。
# urls.py\nfrom django.urls import path\nfrom some_app.views import AboutView\n\nurlpatterns = [\n path('about/', AboutView.as_view()),\n]\n組み込みのジェネリックビューの使用方法の詳細については、次のトピック generic class-based views を参照してください。
\n誰かが私たちのライブラリに HTTP 経由でアクセスして、ビューを API として使用したいという状況を考えてください。API クライアントはたびたびコネクションを張り、最終訪問日時以降に出版された本のデータをダウンロードするとします。しかし、新しい本の情報が存在しない場合には、データベースから本のデータを取得し、レスポンステキストをレンダリングし、クライアントに送信し返すための CPU タイムとバンド幅は無駄になってしまいます。最新の本が出版された時点で API に問い合わせた方が好ましいかもしれません。
\nそのために、URLconf 内で、本のリストビューへの URL を次のようにマッピングします。
\nfrom django.urls import path\nfrom books.views import BookListView\n\nurlpatterns = [\n path('books/', BookListView.as_view()),\n]\nそして、ビューには次のように書きます。
\nfrom django.http import HttpResponse\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass BookListView(ListView):\n model = Book\n\n def head(self, *args, **kwargs):\n last_book = self.get_queryset().latest('publication_date')\n response = HttpResponse(\n # RFC 1123 date format.\n headers={'Last-Modified': last_book.publication_date.strftime('%a, %d %b %Y %H:%M:%S GMT')},\n )\n return response\nビューが GET リクエストからアクセスされた場合、レスポンスにはオブジェクトリストが返されます( book_list.html テンプレートを使用しています)。しかし、クライアントがHEADリクエストを発行した場合、レスポンスは空のボディを持ち、 Last-Modified ヘッダーは最新の書籍がいつ発行されたかを示します。この情報に基づいて、クライアントは完全なオブジェクトリストをダウンロードするかどうかを判断します。
As well as the synchronous (def) method handlers already shown, View\nsubclasses may define asynchronous (async def) method handlers to leverage\nasynchronous code using await:
import asyncio\nfrom django.http import HttpResponse\nfrom django.views import View\n\nclass AsyncView(View):\n async def get(self, request, *args, **kwargs):\n # Perform io-blocking view logic using await, sleep for example.\n await asyncio.sleep(1)\n return HttpResponse("Hello async world!")\nWithin a single view-class, all user-defined method handlers must be either\nsynchronous, using def, or all asynchronous, using async def. An\nImproperlyConfigured exception will be raised in as_view() if def\nand async def declarations are mixed.
Django will automatically detect asynchronous views and run them in an\nasynchronous context. You can read more about Django's asynchronous support,\nand how to best use async views, in 非同期サポート.
\n