MVCフレームワークでMとCを分けるメリットは？

プログラミング初心者で御座います。

現在、MVCフレームワークを使って開発をしようと考えており、
PerlのCatalystというフレームワークをちょこっと勉強しました。

そこで1点わからないことが出てきたのですが
MVCフレームワークでM(Model)とC(Controller)を分けるメリットは
何でしょうか？

拙い知識では、処理の流れとして
(1)C(Controller)がM(Model)を利用してデータをやり取りし、
(2)最後にV(View)に投げる
というものになると思います。

V(View)は(1)が完全に終わってから「後はヨロシク」という感じで
丸投げできるので、分ける意味は分かります。

ところが、C(Controller)とM(Model)は行ったり来たりの
やり取りをする必要があるので
複数のファイルに分けると逆に非効率になると思います。

なぜ敢えてCとMを分けているのか教えてください。

No.1 回答者： shogo0809 回答日時： 2007/01/30 22:57

リクエスト値を受け取る等、汎用的な処理をControllerが行うことで

Model側では「やりたいこと」だけを記述すれば済むようになります。

Catalystというフレームワークは使ったことがありませんが
WEBアプリケーションならば

1. Controllerがリクエストを受ける
2. リクエスト内容に従ってModelを呼び出し、指示を与える
3. Modelからの結果に従ってViewを呼び出し、表示する

という流れになると思いますが、この場合「行ったり来たり」は発生しませんよね。
「行ったり来たり」が発生する「MVCフレームワーク」は「使いづらい」というだけではないでしょうか。

この回答へのお礼

なるほど！
確かに「行ったり来たり」は発生しませんね。
> 「行ったり来たり」が発生する「MVCフレームワーク」は
> 「使いづらい」というだけではないでしょうか。
納得です。
ありがとうございました！

お礼日時：2007/01/30 23:42

No.2 回答者： ngsvx 回答日時： 2007/01/30 23:25

まず、それぞれの意味について再確認しておいてください。

http://ja.wikipedia.org/wiki/MVC

MVCにおいてmodelは中核の部分で、人間が直接操作できるならいいのですが、そうはいかないためVIEWが存在します。

Controllerはmodelとviewの接続役です。

modelとControllerが一緒になるということは、modelが特定の場面だけで使うようになっているということになります。

本来、MVCに分離しているのは、データの再利用をするためで、特定の場面でしか使えないのは問題です。

MVCの考え方はオブジェクト指向と密接な関係がありますので、こちらも学習してみてください。

この回答へのお礼

そういうことなのですね。
よく理解できました。
ありがとうございます！

お礼日時：2007/01/30 23:43

No.3 回答者： us123 回答日時： 2007/04/02 09:15

MVCに対する考え方や捕らえ方も変わってきています

初期の「smalltalk」のMVCは最近の「Squeak（morph）」では十分な説明にならないように思います

MVCに疑問をもたれたら一度「Smalltalk」を調べ、「Squeak」で確認されることをアドバイアスさせていただきます

使わないと損をするModel-View-Controller
http://www.jac-net.com/~tarzan/smalltalkers/mvc/ …

How to use the MVC elements (an example)
http://wiki.squeak.org/squeak/478