- 2008年3月29日 11:53
- しらべる
PureMVCを実装するときに実装側に必要なクラス構成と、
そこで必要な処理をメモとして簡単にまとめてみました。
まだソースは読みきれていないので、ざっくりとした基本的な解釈です。
場合によっては過不足あるかも知れませんが、
いちおう一般的なFlexアプリを想定した場合です。
【Controller】
●アプリケーションファイル(MXMLまたはSpriteの拡張クラス)
・Facadeクラスをインスタンス化
・アプリケーションをスタートアップイベント識別子と関連付けてFacadeに登録
●Facadeの具象クラス
・スタートアップイベントと各ビジネスイベント識別子を定義
・スタートアップイベントと各ビジネスイベントを、
対応する各Commandクラスと関連付けて登録
●Commandの各具象クラス
≪スタートアップCommand≫
・初期化した各ProxyをFacadeに登録
・各Viewコンポーネントで初期化した各MediatorをFacadeに登録
≪各ビジネスCommand≫
・引数から受け取ったVOを、Facade経由で参照したProxyで
処理した結果などをビジネスイベントとして発行
【Model】
●Proxyの各具象クラス
・自クラスの識別子を定義
・自クラスの識別子と、自クラスで保持する汎用プロパティ"data"の実際の型
をsuperコンストラクタの引数として登録
・ビジネスロジック各種
・汎用プロパティ"data"の暗黙getterを用意すると便利
●VO(Value Object)
・Bindable宣言
・アクセサメソッド
【View】
●Mediatorの各具象クラス
・自クラスの識別子を定義
・自クラスの識別子と対応するViewコンポーネントを、
superコンストラクタの引数として登録
・自クラスのコンポーネントイベントハンドラをViewコンポーネントの
コンポーネントイベントリスナに登録
・コンポーネントイベントハンドラとその内部でのProxy呼び出しによる
ビジネス処理、必要に応じて結果をビジネスイベントとして発行
・自クラスが処理する各ビジネスイベントを登録
・各ビジネスイベントの共通ハンドラ
●各Viewコンポーネント(MXML)
・各コンポーネントイベントのMetadata定義と、コンポーネントイベント識別子の定義
・VOのインスタンス化
・VOとコンポーネントのデータバインド
・コンポーネントとコンポーネントイベントの関連付け
大体こんなもんでしょうか。
Mediator内でコンポーネントのイベントとビジネスイベントが
交換されるような感じになるので、多少すっきりしない感じがある。
その他は概ねキレイで好印象。
どっちにしても複数画面、マルチコンポーネントなど、
ある程度の規模でないと恩恵を受けづらいとは思いますが、
ソースを見るとクラスが思ったより少ないというか、本当にミニマムで、
さすがPureというだけあるなぁと納得してしまいました。
