「PureMVC」の編集履歴（バックアップ）一覧はこちら
「PureMVC」(2010/06/21 (月) 16:10:44) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
＜PureMVCの批評と図式＞
１．PureMVCの批評
|項目名|PureMVC|批評|
|理解しやすさ|◎|イベントを一元管理化しているので、イベントと実行されるロジックが理解しやすいです|
|導入しやすさ|○|Cairngormを元にしていることから、Cairngormが導入できるならより簡単です|
|コーディング量|×|１イベントにつき、１実行ロジックというプログラムになってしまいますので、コーディングの量はどうしても増えてしまいます|
|用意されているクラス郡の使いやすさ|○|Cairngormとほぼ同じで、既にあるクラス群には明確な役割が与えられており、使いやすいかと思います。|
|テスタビリティ|○|PureMVCTestというものが公式にあります。それを利用することでテストの効率はあがるのではないでしょうか。（サンプルではそれは導入していませんのであしからず）|
|用意されているドキュメントの量|◎|やはりこれもほとんどが英語です。しかし、公式サイトにはさまざまなサンプルがあり、それだけでも参考になるでしょう。|
|サーバー技術との親和性|◎|サーバーとFlexのロジックを分離する、というのもこのフレームワークの目的ですので、サーバサイドの技術を選びません|
|改造のしやすさ|×|１イベントにつき、１実行ロジックということは既に述べましたが、その都合上、どうしても１イベント、複数実行ロジックという改造が難しい点があります（できないわけではありません）。|
|保守のしやすさ|○|１イベント、１実行ロジックですので、イベントを見れば実効されているロジックがわかりますので、あちこち見る必要がなく、見やすいプログラムになります。|
|知名度|×|Cairngormの方が有名かと思いますが・・・。|
|導入しやすい案件規模|画面数が～１００くらいまで|Cairngormのように全部のイベントを一元管理するわけではなく、画面ごとに管理するようになっているので、Cairngormよりは作りやすいかと。|
|教育コースが存在するか|×|今のところ私は教育コースは知りません。独自で解釈しています。|
２．PureMVCのフローチャート図
#image(http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88.gif,width=500,height=300,title=PureMVC_Map)
[[元の大きな画像はこちらから>http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88.gif]]
３．PureMVCの関連図
#image(http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E5%9B%B3.gif,width=500,height=300,title=PureMVC_Map)
[[元の大きな画像はこちらから>http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E5%9B%B3.gif]]
「図の解説」
PureMVCではMXMLから送出されるイベントを最初にハンドルするのはMediatorというクラスです。
CairngormでいえばFrontControllerにあたる部分でしょうか。
ただしこのMediatorクラスはCairngormで言えばViewHelperクラスの役割を
（つまりはイベントを発生させるためのロジック実装）持っています。
このMediatorの中で該当のModel層にあるProxyクラスをインスタンス化、メソッド呼び出しを行って、処理を行います。
実質、このMediatorクラスがそれぞれのクラスを制御しています。
では関連図に出てきた「Façade」というのは何かと申しますと、
グローバルイベントのコントロールを行うクラスになります。
ここでいうグローバルイベントとは、「View層に依存しないイベント」ということになります。
何のことやらわからない、という方もいらっしゃると思いますので、
簡単なパッケージを示しますとPureMVCでは以下のようなパッケージ構成になります
Controller
→ここにFaçadeが入ります。
View
→Mediatorはここですね。
Model
→Proxyがここに入ります。
上記パッケージでいうViewパッケージの中に入らないMXMLのイベントがすべて、
「Façade」クラスによって管理される、そうお考えください。
関連図に描かれている「Façade」クラスにぶら下がっているCommandクラスも
Viewパッケージの中に入らないMXMLのイベントを実行するためのクラスです。
PureMVCの最大の特徴はMediatorクラスにあるといえるでしょう。
Mediatorクラスの中で、イベントマッピングとロジックの呼び出しのコントロールを行っています。
後の細かいところは、
実際にサンプルを動かしてもらったほうが早いでしょう。
※FlexBuilder3のプロジェクトをアーカイブしたものをサンプルとしておきます。
[[サンプルはこちらから>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=samplePureMVC.zip]]
実行していただけるとよりわかりやすいと思います。
[[サンプルの解説はこちらから>http://www39.atwiki.jp/flex_framework/pages/18.html]]
**メリット
+イベントが画面ごとに管理されていて、どのイベントがどのＰｒｏｘｙを呼んでいるかすぐにわかる。
+サーバサイドとのやりとりが窓口がＤｅｌｅｇａｔｅになることにより、サーバサイドからの返却がわかりやすい。
**デメリット
+Proxyクラスが実質的なビジネスロジック層になるので肥大化しやすい。
#comment(title_name=なまえ：,title_ms=コメント：)
＜PureMVCの批評と図式＞
１．PureMVCの批評
|項目名|PureMVC|批評|
|理解しやすさ|◎|イベントを一元管理化しているので、イベントと実行されるロジックが理解しやすいです|
|導入しやすさ|○|Cairngormを元にしていることから、Cairngormが導入できるならより簡単です|
|コーディング量|×|１イベントにつき、１実行ロジックというプログラムになってしまいますので、コーディングの量はどうしても増えてしまいます|
|用意されているクラス郡の使いやすさ|○|Cairngormとほぼ同じで、既にあるクラス群には明確な役割が与えられており、使いやすいかと思います。|
|テスタビリティ|○|PureMVCTestというものが公式にあります。それを利用することでテストの効率はあがるのではないでしょうか。（サンプルではそれは導入していませんのであしからず）|
|用意されているドキュメントの量|◎|やはりこれもほとんどが英語です。しかし、公式サイトにはさまざまなサンプルがあり、それだけでも参考になるでしょう。|
|サーバー技術との親和性|◎|サーバーとFlexのロジックを分離する、というのもこのフレームワークの目的ですので、サーバサイドの技術を選びません|
|改造のしやすさ|×|１イベントにつき、１実行ロジックということは既に述べましたが、その都合上、どうしても１イベント、複数実行ロジックという改造が難しい点があります（できないわけではありません）。|
|保守のしやすさ|○|１イベント、１実行ロジックですので、イベントを見れば実効されているロジックがわかりますので、あちこち見る必要がなく、見やすいプログラムになります。|
|知名度|×|Cairngormの方が有名かと思いますが・・・。|
|導入しやすい案件規模|画面数が～１００くらいまで|Cairngormのように全部のイベントを一元管理するわけではなく、画面ごとに管理するようになっているので、Cairngormよりは作りやすいかと。|
|教育コースが存在するか|×|今のところ私は教育コースは知りません。独自で解釈しています。|
２．PureMVCのフローチャート図
#image(http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88.gif,width=500,height=300,title=PureMVC_Map)
[[元の大きな画像はこちらから>http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88.gif]]
３．PureMVCの関連図
#image(http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E5%9B%B3.gif,width=500,height=300,title=PureMVC_Map)
[[元の大きな画像はこちらから>http://www39.atwiki.jp/flex_framework?cmd=upload&act=open&pageid=13&file=PureMVC%E5%9B%B3.gif]]
「図の解説」
PureMVCではMXMLから送出されるイベントを最初にハンドルするのはMediatorというクラスです。
CairngormでいえばFrontControllerにあたる部分でしょうか。
ただしこのMediatorクラスはCairngormで言えばViewHelperクラスの役割を
（つまりはイベントを発生させるためのロジック実装）持っています。
このMediatorの中で該当のModel層にあるProxyクラスをインスタンス化、メソッド呼び出しを行って、処理を行います。
実質、このMediatorクラスがそれぞれのクラスを制御しています。
では関連図に出てきた「Façade」というのは何かと申しますと、
グローバルイベントのコントロールを行うクラスになります。
ここでいうグローバルイベントとは、「View層に依存しないイベント」ということになります。
何のことやらわからない、という方もいらっしゃると思いますので、
簡単なパッケージを示しますとPureMVCでは以下のようなパッケージ構成になります
Controller
→ここにFaçadeが入ります。
View
→Mediatorはここですね。
Model
→Proxyがここに入ります。
ただしProxyクラスはサーバーとのやり取りに特化したクラスです。
このクラスがModelといえるのかは少々疑問ですが。
上記パッケージでいうViewパッケージの中に入らないMXMLのイベントがすべて、
「Façade」クラスによって管理される、そうお考えください。
関連図に描かれている「Façade」クラスにぶら下がっているCommandクラスも
Viewパッケージの中に入らないMXMLのイベントを実行するためのクラスです。
PureMVCの最大の特徴はMediatorクラスにあるといえるでしょう。
Mediatorクラスの中で、イベントマッピングとロジックの呼び出しのコントロールを行っています。
後の細かいところは、
実際にサンプルを動かしてもらったほうが早いでしょう。
※FlexBuilder3のプロジェクトをアーカイブしたものをサンプルとしておきます。
[[サンプルはこちらから>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=samplePureMVC.zip]]
実行していただけるとよりわかりやすいと思います。
[[サンプルの解説はこちらから>http://www39.atwiki.jp/flex_framework/pages/18.html]]
**メリット
+イベントが画面ごとに管理されていて、どのイベントがどのＰｒｏｘｙ（あるいはサーバーにアクセスしないMediatorクラスのメソッド）を呼んでいるかすぐにわかる。
+サーバサイドとのやりとりが窓口がProxyになることにより、サーバサイドからの返却がわかりやすい。
**デメリット
+Mediatorクラスが実質的なビジネスロジック層になるので肥大化しやすい。
#comment(title_name=なまえ：,title_ms=コメント：)
