web-dev-qa-db-ja.com

Django CBVとFBV

多くのアプリを含む大規模なDjangoプロジェクトを作成するために、最初の考えはクラスベースビューを使用することでした（Djangoチュートリアルが強調しているようです）。しかし、各アプリへの多くのカスタマイズ（各ページの複数のフォームなど）により、非常に面倒になり、@require_GETや@login_requiredなどのデコレーターを追加するだけで、関数ベースビューを実装する方がはるかに簡単になり、認証が簡単になり、メソッドはサポートされていないメッセージであり、CBVに戻ることは絶対にないと確信しています。

長期的なサポートの観点から、CBVよりもFBVを選択することに問題がある人はいますか？私は短期的に何かをして、長期的には害を及ぼし、おそらくカスタムのクラスベースビューで解決できるでしょうか？

更新 2014年12月

CBVsの完全な擁護者になりました！二度と戻りません！再利用性、継承、ミキシングにより、完全に再利用可能な柔軟なシステムが実現します。 CBVのおかげで、使用したコードの量が大幅に削減されました。確かに学習曲線があり、結果はすぐにはわかりませんでしたが、リファクタリング後は満足できませんでした。大規模なプロジェクトでは、CBVが必要であるようです。

pythondjango
4
C.B.

多くの場合、パッケージからコードにドロップダウンする必要がありました。それらのいくつかはFBVであり、いくつかはCBVです。 私は常にクラスベースのビューで苦労します。理解するのが難しくなります。特に継承はデバッグが面倒です。

私自身のコードは関数ベースです。私が探しているものを見つけるのはとても簡単だと思っています。結局のところ、ほとんどのデバッグはURLで始まります。 urlファイルを見るだけで、viewsファイルで何を探すかがわかります。 （POST etc ...の場合）たくさんのボイラープレートがある場合でも、ビューは非常にわかりやすいですが、基本的には1か所で問題ありません。

クラスベースのビューでは、何が実行されているかがわかりにくくなります。何かが他のものから継承している場合、フローは親と子の間を行き来します。これはデバッグには適していません。

4
Carlos

CBVは、コツをつかめば、多くのことを簡単にする傾向があります。すべてに対してTemplateViewをサブクラス化するだけの場合、すべてが非常に複雑に見えるかもしれませんが、CBVは、本当に必要なときに多くの不要な定型文を取り除きます。

CBVは、物を一口サイズのピースに整理するのにも役立ちます。ビューに使用されるテンプレートの名前は、ほとんどの場合、template_name変数になります。関数がGETリクエストを受け取るとどうなりますか？ get（）を呼び出します。役職？それがpost（）です。複数のコードパスを持つ代わりに、2つの相互に排他的な関数があり、それぞれ独立して異なるシナリオを処理します。私の文脈には何がありますか？ get_context_dataを確認してください。 DBオブジェクトに関する情報を表示する必要がありますか？ URLのPKとビューで定義されたモデルを使用して、DetailViewを作成します。 DBルックアップを手動でコーディングする必要はありません（必要に応じて、クエリセットを特殊化できます）。フォームを処理している場合は、すべての検証が実行されます。次に、form_valid（フォームが有効なときに実行されます）を定義するだけで、おそらくデフォルトでform_invalidに煩わされる必要もありません。フォームのエラーのあるページを呼び出すだけです。

CBVを効果的に使用するための鍵は、適切なシナリオに使用するCBVを知ることです。オブジェクト作成フォームを表示し、それを検証し、オブジェクトを作成するFBVを作成するのは難しいですが、CreateView CBVにはフォームクラス、モデルクラス、およびテンプレート名が必要です。 DetailViewは、データベースから情報を吐き出すのに最適です。年/月/日の検索が役立つブログのようなことをしている場合、その大部分を自動化する6種類の日付ベースのCBVがあります。

最も注目すべきは、FBVはモノリシック関数を作成する以外に選択肢がなく、FBVでは非常に単純なビューがより速く簡単になる可能性がある一方で、CBVがレンダリングプロセスの各ステップ（ディスパッチ、テンプレートの取得、さまざまなリクエストタイプの処理）をカプセル化するという事実です。 、コンテキスト変数の受け渡し、フォームの検証など）により、リモートで複雑なものでも簡単に分解できます。また、デフォルトは非常に健全であるため、通常、ほとんどのCBV関数を宣言する必要はありません。 CBVにほとんどの作業を任せると、CBVに対する感謝の気持ちが高まります。

私が非常に役に立ったと思ったいくつかのヒント：

  • https://github.com/brack3t/Django-braces -中かっこはCBVミックスインライブラリで、CBVに役立つ多くのミックスインを提供します。 FBVを使用して@login_requiredで装飾する代わりに、ビューをLoginRequiredMixinのサブクラスにすると、同じことができます。また、スーパーユーザーアクセス、アクセス許可ベースのアクセス、さらにはAPIのJSONアクセスとAJAX呼び出しのミックスインもあります。

  • デコレーターに完全に依存している場合でも、CBVでディスパッチ関数を装飾することにより、CBVにFBVデコレーターを使用できることに注意してください。結果として、以下は同等です。

    @login_required
def FunkyView(request):
    return HttpResponse("Funky!")

class ClassyView(View):
    @login_required
    def dispatch(self, request, *args, **kwargs):
        super(ClassyView, self).dispatch(request, *args, **kwargs)

    次のように、URLConfのas_view関数を装飾することもできます。

    url(r'^classy/$', login_required(ClassyView.as_view()), name='decorated_classy')

  • http://ccbv.co.uk/ はクラスベースビューの究極のリソースであり、CBVコードを表示したり、何から何が継承されているかを確認したり、関数が利用できる場所を確認したりする簡単な方法を提供します。

3
Seven Deadly Sins