MVCについて 概念編

プログラミングにおけるMVCとは、Model-View-Controllerという概念に沿って開発するプログラミング手法の事です。
すでに語り尽くされているものですが、個人的なMVCに対する見解をまとめます。

Controller

一般的に、入力に対応するModelを呼び出す概念となっている。
入力パラメータによる分岐なども責務とされている事が多い。

複雑な分岐処理が多い場合、ファット(肥大化した)コントローラーとなり、見通しが悪くなる事が多い。
MVCへの理解が低い場合に、最もステップ数が多くなりやすい部分。

Model

いわゆるビジネスロジックを中心に、データやその振る舞いを実装する。
Ruby on RailsのActiveRecordのように、ModelとDAOが同一のものとして扱われる場合、
意識しないとビジネスロジックとデータアクセスのロジックが密結合になりやすい。

実装者の個性が特に出やすい部分。
チーム開発の場合は、まずModelの設計方針について検討するべき。

View

User Interface に関わる部分を実装する。
Controllerを呼び出すエントリポイント、Modelをどう表示するかを表現する。

Windows Formsであれば、FormやControlの表示位置、設定に関わる実装を行う。
Web ApplicationではControllerやModelから渡ってくるデータを元に表示用のHTMLを構成する。
最近であればデータをJSONやXMLに展開するだけのViewという形もよくある。

あまり実装者によって違いは出にくい層ではあるが、変更要求が最も多い部分であるため、
生産性、保守性を考慮して、テンプレートエンジンやレイアウト設計を検討する。

全体を通して

特にControllerとModelの責務が曖昧なため、採用するMVCフレームワークと実装者のスキルレベルによってはあっというまにスパゲティができかねません。
ロジックが特に複雑な場合は、Modelをデータ中心の層とロジック中心の層の2層にするなど、MVCの3層に拘らない方が良いというのが持論です。
Windowsアプリ等の場合は、ViewとControllerが一体化しやすい。ViewとControllerの間に1層増やすなどの工夫が後々効いてくることもあります。
考える範囲をコンパクトにするのがプログラミングの基本です。

10年以上MVCを採用したプログラムを書いてきているが、MVCは未だに廃れていません。
MVVMのように、MVCをより理想に近づけた手法も登場しているものの、実装が複雑なモデルは現場で採用しにくいのが現実です。
細かい部分を考えると問題も多いMVCだが、敷居の低い代替案も無いため、今後もMVCは主流のままでしょう。
とっかかりがシンプルなのがMVCの良いところかと思います。

今後、実装編等も書きたい。