MVC

モデル・ビュー・コントローラー(Model View Controller)の略である。

モデル(Model)

ビジネスロジックを記述する場所である。
つまりは、受け取ったデータの計算などを担う場所である。

データベース処理を担う場所という認識が大きいが、それは間違いである(詳しくは後述)。

むしろ、ビジネスロジックがデータベースを扱う事になり、
機能的には、データベース周りしか強化する部分がなかったため、
モデルはデータベースに関する機能しか有していないと言える。

ビュー(View)

見た目を担う部分である。
コントローラーから渡された情報を出力する役割を持つ。

CakePHPやLaravelといったウェブアプリ用フレームワークでは、
HTMLテンプレートとなっている。

コントローラー(Controller)

ビューに表示する情報を処理する部分。

情報を受け取る事もあるが、それらはモデルに渡して処理を行う事となる。
コントローラーにビジネスロジックを書くのは
間違いと言われる所以は、ここにある(詳しくは後述)。

MVCのアンチパターン

モデルの間違った認識

モデルはデータベースに関する処理を担う場所という認識が強く、
SQL文を詰め込まれている光景を、目にした人もいるかもしれない。

また、「コントローラーにビジネスロジックを書いてはいけない」
という記事を見た人も多く、先述の「モデルはSQL文を書く場所」との認識も合わせ、
新たな領域を設け、そこにビジネスロジックを書くという、
異様な光景を目の当たりにした人も、いるかもしれない。

いわゆる「リポジトリパターン」という、「デザインパターン」の一種であるが、
それを「MVC」に加えて適用すると、「MVCR」となるわけである。
すでに「MVC」というデザインパターンが成り立っているのに、
それを破たんさせる必要もないだろう。

そもそも、新たな領域を作る必要のない、効率のよい設計こそ心掛けるべきだろう。
また、モデルを肥大化させるほどの複雑なSQL文を
書かなければいけないデータベース設計自体も見直す必要があり、
むしろ新たな領域を作るという事は、アプリケーション全体を肥大化させる元になる。

なぜモデルは間違われたのか

CakePHPやLaravelにおいて、モデルの機能が、
データベース接続に関する機能が強調されている事が、
モデル誤認識の原因と思われる。

逆に言うと、モデルにおいて強化する部分は、
データベース接続要素ぐらいしかないのだろう。
もうひとつ強いて言うのなら、
ビューからでもモデル呼び出しは良いとされているので、
どこからでも容易に呼び出し可能にしている事だろう。

よって、開発者が説明する事は、データベース接続に関する事しかなく、
それ以外の事に関しては、MVCの基本概念である、
「モデルはビジネスロジックを書く場所」に任せていたのだろう。

しかし、基本概念を忘れ、フレームワークに存在する機能や説明に目が行き、
それに流されるがゆえに、奇妙な設計が出来上がってしまったものと思われる。

そのような基本概念を忘れ、別の概念やデザインパターンをブチ込みまくり、
さらなる奇天烈な状況を生み出している現場もあるだろうが、
いち開発者の立場としては、既に出来上がっている段階で口出しする事も困難だろう。
基本を思い出したくても、現場が基本に則ってない辛さもあるだろうが、
そこはなんとか、適応力を高めるという意味でも、がんばっていただきたいところである。