モデルの真の役割

2017年01月14日

MVCは、CakePHPやLaravelなどのフレームワークが採用し、
実際に「モデル」「ビュー」「コントローラ」の領域が 存在します。
今回は このフレームワークにおけるMVCについて話をします。

MVCのひとつ、「Model」についてですが、
おそらく多くの人が「データベースから値を引っ張り出す場所」と
勘違いしている人も 多いのではないでしょうか。

Wikipediaの説明によると、要はデータの計算や集計を行う要素という事に なっています。

「値を引っ張り出す場所」・・・ たしかに、あながち 間違いではありません。
しかし、それだけがモデルの役目ではありません。
じつはモデルはビジネスロジックを書く場所でもあったのです。

ビジネスロジックを書くためには、データベースから値をとる必要がある。
そのため、モデルにおいては データベースアクセスの機能を高めた。
要は、データベースアクセスの要素は、後から ついてきたわけです。

「コントローラにはビジネスロジックを書くな」と、聞いたりは しないでしょうか。
確かに コントローラは ビジネスロジックを書く場所ではなく、
ビジネスロジックから出た結果を、ビューに渡す目的を持っています。
それはコントローラが肥大化するという理由にあります。

なら、どこにビジネスロジックを書けばよいのか。
モデルはデータベースを管理する場所として 認識されているのであるならば、
消去法として出るのが、独自の領域作成です。
しかし、そうなると 関数またぎやファイルまたぎが増え、
全体の構成が 複雑になるのが 目に見えています
こうなったら「MVC」ではなく「BusinessLogic」のBを取って、「MVCB」になりますね。

なら、モデルに書くと どうなるのか。
モデルからは データベースへのアクセスを 簡易にしてあります。
モデルのクラス内で すでにテーブルが関連付けられているわけであり、
SQL文に テーブル名を書かなくても、SQLを実行する事ができます。

基本的に フレームワークは 解析するものではないため、あくまで個人的な推測ですが、
一度モデルメソッドを呼び出せば、メソッドにアクセスした時点で、
テーブルの情報を キャッシュとしてすべて取得し、キャッシュをテーブルと見立てて、
疑似的に データベースアクセスを実現している
可能性もあります。
もしそうであれば、メソッド内で 何度SQL文を実行しようが、
データベースへの負荷は ほとんど かかりません。

・・・と思ってはみましたが、よくよく考えてみれば、
テーブルの全データを PHPのキャッシュとして持つには、かなり酷な話かもしれません。
やはり 同じモデル内と言えど、その都度 データベースにアクセスしているのでしょう。

しかし、全データをキャッシュに取得して・・・ のような機能がなくとも、
モデルが データベース処理を担う要素と 勘違いされたのにも理由があると思います。
それは、モデルにはデータベース処理以外に、特別な機能がないからです。

ビジネスロジックは 普段のコードで書けばいいため、
モデルには それを補助するための機能や 特筆するべき内容がない。
だから、データベース処理の機能ばかりが目立ち、
「モデルはデータベース処理を担う場所」と 思い込まれるようになったのでしょう。

CakePHPの説明にも、具体的に「ビジネスロジックを実装するアプリケーションの部品」と記述されていました。
https://book.cakephp.org/2.0/ja/cakephp-overview/understanding-model-view-controller.htm

「MVC」自体も、もともとは フレームワークの構造ではなく、
開発における概念のひとつであった事も、忘れては いけないでしょう。
フレームワークの説明から MVCを調べるのではなく、
MVCそのものについての認識が必要であり、
また、フレームワークにない機能は、「実装できなかった」「使ってはいけない」のではなく、
「既存の方法で充分なため、実装しなかった」という事も 考えられます。
フレームワークが搭載されている機能に 流されるだけでもダメなのでしょう。

Pocket