なぜビューにしないのか。

http://d.hatena.ne.jp/noopable/20090201/1233445916
↑で書いた、

ビューに該当する部分はビューへ、モデルをコントロールする部分はモデルへと分離していけば、
きれいなMVCにはなるかもしれない。無論、それでもいい。

ルーティングの重み付け

この部分、なぜ素直にMVCに分類しないのか。フロントコントローラーからルーティングを経てコントローラーに処理がわたるわけだが、URLはユーザーと直結している部分。ロジックとしてはユーザーロジックが中心となっていて、システム内部とのインターフェースはビューであるということ。
表現が下手でわかりにくいが、

1. ユーザー
2. インターフェース（ビュー）
3. システム（モデル）

概念的なレイヤーはこうなる。
ところが、MVC構成といわれるWebアプリ側の処理は、モデルを操作してから「表示」するためのビューになっている。
確かに、コントローラーがモデルを操作してビューに割り当ててプッシュするというのはシステム構造的には自然だ。
しかし、ユーザーフレンドリィなシステムを組みたいと考えるなら、ユーザーとのインターフェースになるビューに対する重み付けをもう少し増やすべきではないのか。

ルーティングからページクラスへ

情報はプッシュしてプルしての連続であるとすれば、ユーザー側のロジックを記載する部分が必要になる。
それをルーティングにギュッと押し込めてもいいのだが、そうすると複雑なロジックをすべてルーティングの正規表現の中に押し込めなければならなくなる。
ページクラスはその問題を解決するための方策。
システムをU字型に構成する。アクセスフローとしては

1. ユーザー
2. ルーティング
3. ページクラス
4. コントローラー
   1. モデル操作
   2. ビューへ割り当て
5. ビューで出力

ページクラスを挟むことで、ページのバリエーションをコントローラーやルーティングから抽出するのが狙いとなる。