コントローラーを表層系と処理系に分け、ウィジェットでやりとりする

表層系のページ構成部分と、オブジェクトモデルの処理系を区分したい。コントローラーと一口に言っても、ビューを制御するコントローラーと、モデルを制御するコントローラーがある。それぞれから、ビューに該当する部分はビューへ、モデルをコントロールする部分はモデルへと分離していけば、きれいなMVCにはなるかもしれない。無論、それでもいい。
ただ、感覚的にはどうも、ビューを制御するコントローラーに対するニーズは多様化する傾向があるが、モデルを制御するコントローラーは、極シンプルな基本処理と複数の処理を連動したトランザクションでかっちりした構成が合う。
一つの管理操作を、複数の表層で利用したり、部分的に処理したりといったケースを考えると、ルーティング-コントローラー-ビューへの流れが一本になっていると、コントローラー内での条件分岐が必要になり再利用性が落ちる。ルーティングとコンフィグを対応させて条件をインジェクションする形にすればコントローラー内は多少すっきりするとは思うが、コントローラーの作成に規約が増えて作りにくくなるし、構成の可読性が落ちる。たぶんそれは、机上の美学にすぎない。

ルーティングからページクラスに来た処理は、ページクラス特有のロジックを処理しつつ、サービスを直接起動して自前でwidgetを作成したり、サービス群をアクションスタックに入れる。サービス群は処理結果またはモデル参照をwidgetに格納する。そのwidgetをレスポンスオブジェクトのDOM風ツリーにインストール、ビューに処理を廻す。ビューは受け取ったスタックのwidgetのrenderをコールするとツリーを辿って出力される。

という流れを想定している。キモになるのは、レスポンスオブジェクトの改造と、widgetの設計かもしれない。