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がどのように実装されているかを見ていきます。
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の実装
こちらもまずはどのように実装されているか見ていきます。
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つのビューも記述されればアプリの血となり肉となります。