>641
やっぱ、そこか。
例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。
で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。
で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。
これをMVCのうち、MとCのどっちに置くかの問題。

MVC、MVCって言ってるけど、本質的には4層なんだよ。
処理の振り分けに1層を割くならば、4層なくてはならない。
処理の振り分け=呼び出すCの決定（ディスパッチャ）→どのMを呼び出すかを制御する（コントロール）
　→データを実際に扱う（モデル）→表示（ビュー）、となる。

実際のフレームワークだと、RailsやZendはDispatcherが振り分けを担当し、制御はコントローラが執っている。
（だから、おまいの目から見れば、コントローラは仕事をやりすぎに見えるはず）
SymfonyやCakeだとControllerがディスパッチを担当し、制御はActionが執っている。
CodeIgniterだとディスパッチは単一のエントリポイント（リクエストを受けるphpファイル）であるindex.phpが行なって、制御はCが行なっている。