Progression で MVC的なサムシング (3)

なんか、新たに色々と本を読んでいたら思う所があったので、再び、グチグチとMVCの話を。

結論。

• MVCのセットは、「1アプリケーションに1セット」ではない！
• SceneObjectは、swfレベルではModel層っぽく、アプリケーションレベルではコントローラー層っぽいヤツとして扱う。

視点をどこにおくかで、MVC構造は変わるらしい。

事の発端は、「WEB+DB vol.53」の”MVC入門編”という記事。17ページ目の図4。

MVCの構造自体が、入れ子のようになるのが常なようです。
（挿絵を準備中）

自分の中でも、そうなんじゃないのかなー、とは思いつつ、スタンダードな方法が何なのかは
全く分からない状態だったので、この記事に背中を後押しされた気分です。

swfを作る際に（特に、設計する時に）意識しなきゃいけないのは、
アプリケーションレベルがどの範囲で、自分が作るswfがどのレベルのモノなのかを把握する事
なんでしょうね。

そこを意識して、自分の目線を定めないと、うまい事設計できないのかなー、と。

Progressionの上手い扱い方 提案1

php + データベース + swf (Progression) っていう案件の場合、アプリケーションレベルでのMVCは、

[アプリケーションレベル]

• Model : データベース
• Control : swf と php
• View : swf

となると思います。

さらに、入れ子になるようにswf の中にもMVCが存在するわけですが、その際、Progression をどう使って行けば、
上手いこと外部と連携しつつ、swf内の秩序も守って行けるのかを考えた結果が、以下のようなクラス図。

AppModelのprotected static なメンバとして、php と連携すべきデータを保持して、そのサブクラス（MySceneObject）で
適宜phpに送ったり、phpからデータをもらったりする。
Model層としての役割は、AppModelクラスが担当していて、アルゴリズム的な実装はすべてこのクラスに書く。

MySceneObjectは、ルートシーンにaddSceneされるようになっていて、
swf内のコンテンツは、基本的にはMySceneObjectインスタンスのシナリオ通りに動く。

モデル層に変更が必要な場合は、MySceneObjectがスーパークラスのアルゴリズムを利用して
変更を加えていく事になります。

Progressionインスタンスは、swfレベルでのコントローラー層となって、適切なシーンに状態遷移をしてもらう。

・・・みたいな流れでしょうか。


大雑把にまとめれば、

SceneObject（のサブクラス）は、swfレベルではモデル層と状態保持（ステートパターンのステートクラス？）の役割をして、
アプリケーションレベルでは、コントローラー層として働く。

という感じでしょうか。

swfレベルで、さらに入れ子MVCが必要な場合

そういう場合は、おそらく「このシーン以下では、別のモデル層が必要だなー」みたいな状況だと思います。
このシーン以下はギャラリーコンテンツ、みたいな。

そういう時は、AppModelとは別に、SubContentModelクラスをSceneObject継承で作って、
同じくprotected static なメンバを作って・・・みたいな感じにすればいいんじゃないんでしょうか。
（参考：Progression で MVC的なサムシング (2)）

まとめ

ちょっと雑な説明かもしれませんが、要するに、
MVCは入れ子入れ子で作ってもいいし、なにより、巨視的にアプリケーションを見つめて設計したらいいじゃない、って事ですかね。