MVCとPAC - noopな日々

Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及

MVC アーキテクチャはある程度の規模になると限界が訪れる。
http://c2.com/cgi/wiki?RecursiveModelViewController
http://d.hatena.ne.jp/noopable/20090127/1233014697
この、1999年の記事でPACについて触れられているが、PACはMVCのスケール問題、その他を解消しうる。MVCでも、RecursiveMVCでMVCに階層構造を持ち込んで解決するという方法もあるらしい。
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#fig:pac
似たようなことは誰でも一度は考えることだろうが、その思いつきを発表して名前を付けて共有するところまでいくと急速に受け入れられていくように思う。皆が大変な思いをしていても、Struts的MVCやRoR的MVCは依然として人気があるのもうなずける。

Zend_FormはPACに近い。

http://d.hatena.ne.jp/noopable/20090126/1232929073
こちらにも書いたが、フォームを大きな機能単位とし、サブフォーム、エレメントのそれぞれをエージェントと見做すような粒度を調整した使い方ができる。単純なMVCでは実現できない複雑な階層を持ったモデルに対するコントロールを実現するには、各モデル要素がエージェント的要素を持っていないと難しい。Zend_Dojo_Formでは各エレメントがクライアントでのバリデーションまでサポートする。実際フォームでは各要素とビジネスロジックが密接に絡むので、各エレメント、各フォームレベルでエージェント機能が欲しくなる。
PACの一般的な仕様ではエージェント間はメッセージングで結ばれるのに対し、Zend_Formで採用されている形式は単独ではエージェントのようだが、ツリー構造、コンポジット構造になっている。そのため、子側から親を参照できない。PACでは、子エージェントに発生したイベントは親エージェント＝＞兄弟エージェント＝＞祖先エージェントという具合にメッセージングによって伝達されるのでアーキテクチャ的には別ものではある。

yii Frameworkのようにコンポーネント指向であると、PAC的な実装と相性がよい。

詳細なコントロールにはPACが合う。包括的なコントロールには冗長か。

たとえば、キャッシュの調整を行う場合、PACを使っていると、各エージェントでのキャッシュ状態の保持、および更新イベントの伝達などにはPACでモデルが作成されていると制御しやすい。

アクションコントローラーをPACエージェントに

Zend Frameworkのアクションコントローラーには必要な機構がほとんど備わっているので、PACエージェント的に使っても自然。テスト実装した限りでは、かなり使えるという感触を持っています。

PACもいいけどMVCもね

しかし、PACにも扱いにくい点はあるように思う。
大規模開発には二つの視点が必要なんじゃなかろうかと。
MVC的にシステム全体をすっきり分割するモデルと、大きくなりすぎた焦点を任意の粒度にフォーカスする粒度調整。すくなくとも、MVCでうまくいっている部分までPAC化する必要はないし、PAC化した方が制御しやすいものを大きなMVCに分散させる必要はない。
量子論と、相対性理論がある領域ではそれぞれに限界があるように、MVCとPACはたがいに補えるような柔軟性を与える構築パターンを持たせてもよいような気がする。

Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及

Zend_FormはPACに近い。

詳細なコントロールにはPACが合う。包括的なコントロールには冗長か。

アクションコントローラーをPACエージェントに

PACもいいけどMVCもね

関連：参考