先日、niumさんにProgressionフレームワークのワークショップを開いていただき、参加してきました。
Progressionはフルフラッシュサイト製作を支援するフレームワークです。
Progression：
http://progression.libspark.org/
今回のエントリーはProgressionを使用した設計のパターンを考えてみました。
クラスベース開発のチュートリアルとコードでなんとなく全貌を把握した後、
ワークショップの際にniumさんにいろいろ質問したことうけて修正、加筆したものです。
ただし、僕はまだProgressionで実案件をこなした事がなく机上の空論である可能性がとても高いのであくまで考えるためのスケッチとして見てみて下さい。
パターン1 Modelなし
静的なHTMLをそのままFlashにしたようなサイトで、チュートリにあるような、ベーシックなパターンです。
Progressionが想定しているパターンだと思われます。
アプリケーションは状態を持つことができますが、各状態が共有するモデルは持ちません。
本来モデルになるデータは、各シーンに分散して実装されます。
シーンが共有するモデルが存在しないときにぴたりとはまります。
パターン2 Modelあり（シーンとViewが1:*）
MVCを適用したパターンです。
シーンはコントローラ層として働きます。
Progressionを使用して、シーン間でモデルを共有する必要がある時、
モデルを誰の所有物とするかという問題が出る事が予想されます。
上記の例では、ルートシーンが所有していますが、Applicationに持たせるべきかもしれません。
（その場合はProgressionインスタンスが発行するイベントを使ってモデルを操作することになります。）
また、DomainModelがあればApplicationに持たせるべきでしょう。
このパターンもProgressionと相性が良さそうです。
詳細：
ModelはProgressionフレームワークのルートシーンに所有される。
GUIの入力はシーンがキャッチし、シーンはルートシーンを経由してModelを操作する。
また、Modelの状態変化はApplicationControlerに通知され、
ApplicationControlerはProgressionのcurrentシーンに対して操作を行う。（ポリモーフィズム）
これにより、Viewは更新される。
シーンはViewの操作を委譲された後、必要なら別のシーンへ遷移する。（Stateパターン）
パターン3 Modelあり（シーンとViewが *:1）
ユーザから見て、ページが遷移しているようには見えないタイプのフルフラッシュサイトはシーンとViewの関係が「多:1」となります。
niumさんによれば、Progressionではあまり想定されていないケースのようですが、上記のパターンでうまくいくかもしれません。
ルートシーンをViewを所有するControlerとし、そのほかのシーンをStateパターンにおけるStateとして使用します。
ルートシーン以外はViewの参照を持ちません。Viewの操作は全てルートシーンに委譲されます。
問題点として、ルートシーンにViewの操作の実装が集中するため、ルートシーンが肥大化する事が考えられます。
詳細：
ルートシーンは全てのViewを所有とView操作のクライアントとしての責務を受け持つ。
ルートシーン以外のシーンは、アプリケーションの状態を表すStateとして機能させる。
シーンはApplicationControlerからViewの操作を委譲された際、ルートシーンの該当するメソッドを呼び出すことでViewの操作を行う。
という感じで考えてみましたが、
やっぱり実装してみない事には何とも言えませんね。
これから使えるところでは積極的にProgressionを使っていって、こんなパターンが出来たよとレポートしていきたいです。