はじめに
（以下は、会社を代表するものではなく、個人の意見です。）
こんにちは。
Advent Calendar今年初参加です。よろしくお願いします。
何を書こうか迷ったのですが、あまり背伸びして考えすぎても塩といった印象ですので
自分はせっかくなので普段触れているMVCフレームワークについて書こうと思います。
初めてフレームワークに触るということ
自分はおよそ11ヶ月前に、PHPフレームワーク実装デビューしました。
初めてなので正直何がなんだかわかりません。
ソースコードの密林に降り立つおれ。
フレームワークは、アプリケーションの実装を手軽にするもの。
（フレームワークに限らず）便利なツールはそこを突き詰めたものであるがゆえに
たとえわけがわかっていなくてもある程度実装できてしまいます。
ですが少しでも仕組みを理解して、あ、
MVCとは一体何
おい君。逃げちゃだめだ。
MVCの流れを簡単にまとめてみる
MVC、本当にわかってますか？
一言でMVCといっても、人によって解釈が異なりますが
一般的にはUIと内部ロジックを分離するデザインパターンのことで
- model ビジネスロジック
- view: ユーザーインターフェイス
- controller: 入力を受け取りmodelとviewへの命令に変換する
この３つの頭文字をとったものです。
改めて考えてみると、アプリケーションの内容や使用用途によって解釈が異なる
のほうが的を射ているでしょうか。
MVCのいいところ
MVCのメリットは機能が分離して、独立するから
- 分業によりそれぞれの専門家（Viewならデザイナーさんetc）が集中しやすい
- 一つの機能がほかの機能部分の変更による影響を受けにくいので保守性が高まる
ところ、とされています。
この2のほうの話、脇道にそれるかもしれませんが以下を思い出します。
変更する理由が同じものは集める、変更する理由が違うものは分ける。
責任（機能）の分離は保守性を高めたいエンジニアの本能なのかな。
ということは現行のソースコードでも、機能が依存しあっているところに注目だな。
webアプリにおけるMVC
webアプリにおけるMVCの特徴は
インターネットだからHTTPを使うところだ！！そしてHTTPはステートレス。
更に言うと個人情報を扱うならSSL通信が主流の時代。
つまり、$_SESSSION機能でユーザーが入力した情報を引き回すということです。
MVC実装の注意点
MVCモデルを実装するときの注意点として
「ビジネスロジックはmodelに書いて！ファットコントローラはダメ！ゼッタイ！」
とよく言われます。
ファットコントローラというのは、色んな内部処理をコントローラに詰め込んでしまって
ソースコードが膨大かつ読みづらくなってしまうこと。
そして誰もが思う。
MVCを使うためにMVCを使っているわけではないはず、と。
そもそもMVC古くない？
こんな記事を見つけました。
内容としては、MVCモデルという概念を捨てて、関数型プログラミングで実装をシンプルにしようというもの。
問題は、Andre Medeirosが言うようにMVCパターンは“インタラクティブ” (リアクティブではなく)だということです。従来のMVCでは、アクション(コントローラ)はモデルの更新メソッドを呼び、成功したか失敗したかでビューの更新方法が変わります。Andreが指摘するように、この方法が絶対というわけではありません。
たしかに、アプリケーションによってはあっという間にレガシーになってしまうメソッドを書くよりも
内容が単なる計算なのだから計算を書けばいいよなあ
という時もありそう。
仕様からMVCを再解釈しよう
もう一度、webアプリの開発をするという観点に立ち返ってMVC実装をしよう。
それぞれにどのような分担をさせるかは、個人が自覚しているかチーム内で共有されていれば
むしろ再解釈がされていてしかるべきではないでしょうか。
相対的に多少コントローラがファットになっても、目的にかなっていて必要な記述ならば問題ないはず。
たとえば
- model DBにまつわるビジネスロジックだけ。
- view: ユーザーインターフェイス。アプリ設定値（グローバル）。ユーザー入力値起因の計算はここに書いちゃう
- controller: モデルへの命令。バリデーション。セッション情報の管理。viewに出力する値の管理。などなど
とひとまず決めたとします。
決めると。
- 色んな情報が整理できて、混乱せず設計できる。
アプリのリリース日⇒アプリケーションに紐づく設定値⇒設定ファイルに一箇所でだけ代入してグローバルに引き回そう
とある入力値A⇒セッションで引き回す（んだけどDBにはかかわらない）値⇒controllerで処理を書こう
とある入力値B⇒クライアントに報告する値⇒DBに格納する値⇒controllerでバリデーションと型判定を通して、モデルに渡してupdate
■pt(X商品を◯個購入。X商品は一個▲pt）⇒ユーザーに紐づく「◯個」の部分はセッションで引き回す。「◯×▲」の計算はviewに書く。
⇒当初の目的（いいところ）だった責任の分離による保守性の担保をアプリケーションに合わせて適宜行える。
まとめ
MVCの仕組みや使われている経緯、意図を知ることで
そもそもの目的やあらかじめ気をつけておくべきこと、特に気にしなくてもよいことが明確になります。
更に使用するフレームワークが変わった時、使用言語が変わった時など
それぞれどこが違う（変えたいから変わった）のかがわかり理解しやすくなります。
おしまい。