MVC、お前もか - みねこあ

MVC とは、もともとの出自は Smalltalk で、対話型のアプリケーションを作成するためのアーキテクチャのことでした。

Smalltalk なんて知らない人多いでしょうに、普通のプログラミングの話題でこうも顔をピョコピョコ出すのが、なんというか、憂いヤツです。そんな何かと気になるアイツこと、Smalltalk の MVC について、抜群にわかりやすいこちらの梅沢さんの記事をおすすめしておきます。

Happy Squeaking!! -オブジェクト指向再入門- [第五回：デザインパターン事始め]

さて、こちらから引用して、MVC の M、V、C がそれぞれどんなモノかというと、

処理を受け持つ部分は、Modelと呼ばれます。アプリケーションで必要となる実際のデータを保持しており、業務に特化した処理を実行します。(中略)
Modelの状態を表示する部分はViewになります。ビットマップディスプレイ上に表示されるウィンドウや、その中のウィジェット群(メニュー、ボタン、リスト、スライダなど)がビューの候補になります。ビューは、モデルと比べユーザの好みといったものが介在します。そのためモデルに比べて、非常に多様で移り変わりが激しくなる傾向があります。(中略)
3つ組みの最後はControllerです。コントローラは、マウスやキーボードからの入力をイベントとして受け取る役割を受け持っています。GUIの見栄えと操作感覚を現す言葉にLook&Feelという言葉がありますが、MVCにあてはめるとLookがビューでFeelがコントローラということになります。(後略)
Happy Squeaking!! -オブジェクト指向再入門- [第五回：デザインパターン事始め]

と、こんな感じ。

素人が VisualBasic みたいな RAD で GUI アプリを作ると GUI部品のイベントにガリガリコードを書いてしまうような感じになります。が、それらがとっても拡張や保守がし難い（ちょっと変えると直ぐバグる）のは、お仕事プログラマなら大抵経験済みだと思います。そこらへんを何とか出来る賢いアーキテクチャが MVC。

MVCは、単純に、対話型アプリケーションを作る際、変わりやすい Look&Feel から、変わりにくい Model を開放閉鎖原則に従って責務分割した姿です。（と、わたしは思ってる）

MVC がバズワード・・というのはあると思います。今回の話、わたし、sumimさんちのMVC、これでいいのか？にデジャブなネタだなぁ、と思いました。つまり、

「最近は違う」については、JavaServlet勢力が話をややこしくしてる面も有るんじゃないかな。
彼らの言うMVCはMVCですらないと思う。
MVC、これでいいのか？

みたいな話。

Web アプリと普通の GUIアプリでは環境が違うのでアーキテクチャが異なるのは当前です。そんな違ってて当たり前のものに「MVC」と名付けちゃったのは、悪く言えば連想ゲーム、よく言えば MVC のエッセンスを取り出して大きくアレンジ・・になるのでしょうか。ここら辺の事情とかは、うとくてよくわかってません（ごめんなさい）。

ただ、わからないなりに思うのは、MVC を名乗る以上、変わりやすいところ(Look&Feel)と変わりにくいところ(Model)を分離した・・・という最低限のラインは守るべきじゃないかな、とか素人ちっくな理想論。

なのでさとしさんのコレ

　Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を１００％Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくことである。
Life is beautiful: Ruby on Railsの「えせMVC」の弊害

わたしは、しごく MVC 的当たり前発言だなぁ、と思いました。だってこれが意味するのは、ちゃんと拡張に対して開いていて、修正に対して閉じてるってことだもの。

はっきりいって、ロジックをModelに書こうがControllerに書こうが、整合性の考慮漏れは、どうしても出てきます。Modelに書いたからといって、Controllerに書いていたときの考慮漏れが自動的に解決することはないのです。
えせMVCについてそろそろ一言言っておくか - yvsu pron. yas

は、整合性が必要な部分を Model と Controller に分散させるよりは、Model に集めた方がいいんじゃない？・・というのを「MVC」と呼ぶのでは？・・と「Web の MVC」にあまりなじみがないわたしはそう思ってしまう。

Model に集めるのが得策じゃなくて、その点については「修正に対して開いちゃっている」けれど、それをユニットテストで補う・・ってのはアリ（というか普通の話）だと思います。そういうアリナシとは別に、ただ「MVC」という言葉からは違和感あるな、と思ったという素朴な感想。

もし、違和感持つ方が変となるなら、OOP のように「2つのMVC」ってことになるのかしら。MVC、おまえもか。いあいあ、エッセンスのようなモノはあると信じたいデス。

* * *

以下は余談。

出遅れた上、いまさら語ることがなさそうなこの話題なのに、こんなエントリーを作ってしまったのは、

問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。
Life is beautiful: Ruby on Railsの「えせMVC」の弊害

について、ひがさんの

私は、Modelには収まりが悪いビジネスロジックはServiceにおくことをすすめています。この辺は好みで、永続化されないModelにおく方法もあります。
えせMVCについてそろそろ一言言っておくか - yvsu pron. yas

追記:Serviceは永続化されないModelなので、カテゴリはModelです。
えせMVCについてそろそろ一言言っておくか - yvsu pron. yas

がまさに、「Model」と呼ぶべきものを別の名で呼び、「Model」と呼ばれるものが「Model」に足りてない「問題」（そういうのは「語彙の統一」というデザインパターンの精神に反するなぁ）を実証してるようで。おんなじこといったるじゃーん！・・というか。「自作自演乙」みたいな、阿吽なエントリーに、突っ込まずには居られませんでした。

・・・スルー力が足りないわたし。