class-based viewとfunction-based viewの違い

　本稿ではDjangoの実装でよく用いられるけど、似ているからごっちゃになる2つについて説明します。

イメージでとらえる

　具体的な説明に入る前に、まずはイメージで捉えていきたいと思います。

class-based view：お惣菜
function-based view：料理
です。

　お惣菜は、便利です。料理をしたくないときに買ってきたら、すぐ食べることができるし、一定のおいしさは担保されています。しかし、「もうちょっと味濃かったらな」とか「具材の組み合わせがなんか違う」といったような融通の利かなさが出てくるかもしれません。
　一方で料理はめんどくさいです。献立を決めて、食材を選び、調理をしなくては食べれません。おいしさだって「砂糖と塩を間違える」といったべたなミスや、「焼きすぎ、煮込みすぎ」などの調理ミスで左右されます。しかし、自分の思うように作ることができます。味も食材も自分の自由です。

　class-based viewとfunction-based viewも同じ関係です。

どちらがより便利か（実装の容易さ）
おいしさの担保（安全性）
融通が利く（処理の自由さ）
という要素の差があるだけで、本質（食事/ビュー）は変わりません。そこに優劣はなく、用途や目的に応じて適切に使い分けるだけです。

class-based view

class-based viewの実装

　まずはclass-based viewがどのように実装されているかを見ていきます。

views.py

from django.views.generic import TemplateView

class HogeClass(TemplateView):
    template_name = 'hoge.html'
    model = hoge

　最初にTemplateViewをインポートしています。これはDjangoが用意してくれているクラスです。自作のクラスに継承させることで、用意されているメソッドや変数を使えるようになります。
　今回使っている要素は、template_nameという変数とmodelという変数です。
　前者はブラウザに表示させるhtmlファイルを指定する役割を持っています。このクラスが呼び出されたときは、hoge.htmlが表示されるということです。
　後者はこのビューでどのモデルを使うか指定しています。今回はhogeというモデルを使用します。

class-based viewの総評

実装の容易さ：〇
安全性：〇
記述の自由さ：△

function-based view

function-based viewの実装

　こちらもまずはどのように実装されているか見ていきます。

views.py

def hoge_view(request):
    object_list = hoge.objects.hoge()
    return render(request, 'hoge.html', {'object_list' : object_list})

　こちらは前回の記事でも少し書きました。
　まず、hogeというモデルから使うオブジェクトを取得しています。この関数が呼び出されたときに、どのモデルを使うかを指定しています。
　そして、「リクエスト」と「テンプレートに指定するhtmlファイル」、「モデルからのデータ」を返しています。

function-based viewの総評

実装の容易さ：△
安全性：△～×
処理の自由さ：〇

両者比較

違う点

　上述の通り、class-based viewは実装が楽です。継承したら、変数に値を代入するだけで終わります。他にも、使いたい機能があったら関数を呼び出すだけです（今回コードの記述はありません）。
　一方、function-based viewは実装が大変です。変数を代入して、加工して、返す過程を自分ですべて書かなくてはいけません。しかし、その過程を好きに書けるので自由度は高いです。

同じ点

　両者ともにビューなので、やっていることは同じです。今回のコードを見ても、両方とも呼び出されたら「モデルからのデータ」と「表示させるテンプレート」を渡しているだけです。役割は同じなので、過程が異なるだけで同じ結果にはなります。

まとめ

　今回はclass-based viewとfunction-based viewの違いを見ていきました。両者の個性はあれど、本質は変わらないので適した方を使いましょう。
　総菜も料理も食べられればあなたの血となり肉となるように、2つのビューも記述されればアプリの血となり肉となります。