flex_framework @ ウィキ

PureMVC

2010-06-21T16:10:44+09:00

＜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=コメント：)

Cairngormサンプル解説(2

2009-03-19T11:38:22+09:00

さて、ここではCairngormのもっとも重要な部分である Controller層について解説していきます。 Cairngormでは &bold(){「ScriptタグはMXMLの中にはできるだけ書かないようにしよう」} という考え方のもとに作られているのですが、もうひとつの特徴が &bold(){「発生するイベントを一元管理しよう」} というものがあげられます。このイベントの一元管理を実現しているのが Controller層なのです。 Controller層は大きく分けて３つになります。１）SamplecairngormControllerというクラス２）Commandパッケージ３）Eventパッケージ１） SamplecairngormControllerというクラスはイベントを一元管理するためのクラスです。サンプルのソースを解説していきましょう。 package sample.controller.samplecairngorm { import com.adobe.cairngorm.control.FrontController;　　　　　　　･････････････････････・・・・・・・・・・・・・・・・① import sample.controller.samplecairngorm.command.*;　　　　　　･･････････････････・・・・・・・・・・・・・・・・・② /** * イベントマッピングを行うコントローラークラスです。 * このクラスでイベントを一元管理しています。 */ public class SamplecairngormController extends FrontController　　　　　　　　　　　　　・・・・・・・・・・・・・・・・③ { /** イベントを一意に識別するためのイベント名称をここで設定します */ public static const SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENT:String = "clickBtnHelloWorldEvent";　・・・④ /** * コンストラクタです。 */ public function SamplecairngormController():void { super(); // addCommandメソッドで一意に指定したイベント識別名とCommandクラスとのマッピングを行います。 // これによりこの識別イベント名のイベントが発生するとCommandクラスが呼び出されるようになります。 addCommand(SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENT,ClickBtnHelloWorldCommand);　　・・・・・⑤ } } } ①import com.adobe.cairngorm.control.FrontController 　　Cairngormでイベントを一元管理するために必要なFrontControllerクラスをインポートしています。　　後で記述していますが、このFrontControllerクラスを継承することで、　　イベントを一元管理してくれる役割をもったクラスになるわけです。 ②Commandパッケージのインポート　　Commandパッケージに所属するCommandクラスをインポートしています。　　２）のパッケージですね。　　Commandというのはイベントと１対１になるもので、　　イベントが発生した際に、実行されるロジックが実装されたクラスを指しています。　　クラスの内容は２）で解説します。　　 ③FrontControllerを継承したクラスの宣言　　①で出てきたFrontControllerクラスを継承したクラスの宣言です。　　既に記したようにイベントを一元管理するために必要なクラスを継承しているという宣言です。 ④public static const SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENTの宣言　　Eventクラスを作成したときに使う「イベント名」をここで設定しています。　　この「イベント名」がMXMLより送出されれる「イベント名」になります。　　ですので、ここで宣言したイベント名がFrontControllerの中で管理されるようになります。 ⑤addCommand()メソッド　　④で宣言したイベント名とCommandパッケージの中のCommandクラスの名前を引数として　　実行されるメソッドです。　　このaddCommandメソッドこそがCairngormでイベントと実行ロジック実装クラスとをマッピングするメソッドなのです。　　このメソッドでイベントとCommandクラス名を設定しなければ、　　イベントが起こってもイベントに対応した実行ロジックを呼び出すことができません。　　このメソッドはCairngormの中でもっとも重要なメソッドのひとつでしょう。２） Commandパッケージは前述にある実行ロジックの実装クラスのパッケージです。ここでは実際にサンプルアプリケーションのCommandクラスを見てみましょう。 package sample.controller.samplecairngorm.command { import com.adobe.cairngorm.commands.ICommand;　　　　　　　　　　　　　　･････････････････････・・・・・・・・・・・・・・・・① import com.adobe.cairngorm.control.CairngormEvent;　　　　　　　　　　　　　･････････････････････・・・・・・・・・・・・・・・・② import mx.rpc.IResponder;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　･････････････････････・・・・・・・・・・・・・・・・③ import sample.controller.samplecairngorm.event.ClickBtnHelloWorldEvent;　･･････････････････・・・・・・・・・・・・・・・④ import sample.datamodel.ApplicationDataModel;　　　　　　　　　　　　　　　　　　･･････････････････・・・・・・・・・・・・・・・・・⑤ import sample.service.samplecairngorm.SamplecairngormHttpDelegate;　･･････････････････・・・・・・・・・・・・・・・・・⑥ /** * イベントを実際に実行するコマンドクラスです */ public class ClickBtnHelloWorldCommand implements ICommand,IResponder　　　･････････・・・・・・・・・・・・・・・・⑦ { /** * イベント発生後、最初に実行されるメソッドです。 * @param event CairngormEvent */ public function execute(event:CairngormEvent):void　　　　　　　　　　　　･･････････････････・・・・・・・・・・・・・・・・・⑧ { // イベントはCairngormイベントの形でわたってきますので、 // それを専用のイベントにキャストします。 var e:ClickBtnHelloWorldEvent = event as ClickBtnHelloWorldEvent;　　　　･･････・・・・・・・・・・・・・・・・・⑨ // Delegateクラスをインスタンス化する際に自分のインスタンスを渡します。 // これは「IResponder」インターフェースを実装したクラスが自分だからです。 var httpDelegate:SamplecairngormHttpDelegate = new SamplecairngormHttpDelegate(this);　・・・⑩ // Delegateをインスタンス化する際に自分のインスタンスを渡していますが、 // このことにより、下記、メソッドが実行され、HTTPServiceあるいはRemoteObjectでの // サーバー連携の結果が自分のインスタンスの「result」あるいは「fault」メソッドに // 帰ってくるようになります。 httpDelegate.clickBtnHelloWorld(new Object());　　　　　　　　　　　　　　　　　･････････・・・・・・・・・・・・・・・⑪ } /** * Resultイベントハンドラです。 * @param data オブジェクト */ public function result(data:Object):void　　　　　　　　　　　　　　　　　　　　　　　　　･････････・・・・・・・・・・・・・・・⑫ { var model:ApplicationDataModel = ApplicationDataModel.getInstance();　　　　　・・・・・・・・・・・・・・⑬ model.sampleModel.txtField = data.result.docs.doc.say;　　　　　　　　　　　　　　　　・・・・・・・・・・・・・⑭ } /** * Faultイベントハンドラです。 * @param info オブジェクト */ public function fault(info:Object):void　　　　　　　　　　　　　　　　　　　　　　　　　･･････････････････････⑮ { } } } ①ICommandインターフェースのインポート　　ICommandインターフェースはFrontControllerクラスを継承したクラス（サンプルではSamplecairngormController）で、　　addCommandメソッドを実行する際に第２引数として渡していたCommandクラス名を　　確定させるためのインターフェースです。　　つまり、このICommandインターフェースを実装しないと、　　FrontControllerを継承したクラスの中でaddCommandメソッドを呼び出した際に、認識してくれないのです。　　ですので、Commandクラスを作成する際には必ずimplementsしましょう。 ②CairngormEventクラスのインポート　　このCommandクラスが受け取るEventをインポートしています。　　CairngormでのイベントはすべてこのCairngormEventクラスを継承して作られています。　　このあたりについては３）にて解説しますが、　　executeメソッドの第１引数として渡されるクラスがこのCairngormEventなのです。 ③IResponderインターフェースのインポート　　IResponderインターフェースはHTTPServiceでのサーバサイドの呼び出し、　　あるいはRemoteObjectのメソッドを使ってのサーバサイドの呼び出しの際に、　　成功（result）か失敗（fault）かをハンドルするためのインターフェースです。　　これもまたCommandと同様にimplementsしないと、後に出てくるDelegateのメソッドを実行した際に、　　成功したか失敗したかの結果が返ってこなくなってしまいます。　　ですので、Commandクラスを作成する際には必ずｉｍｐｌｅｍｅｎｔｓしましょう。　　 ④ClickBtnHelloWorldEventクラスのインポート　　executeメソッドで実際にイベントを受け取った際に、　　このCommand専用のイベントにキャストするためにインポートしているクラスです。　　ecxecuteメソッドが呼び出されたときに引数としてCairngormEventをもっているのですが、　　多くの場合、呼び出されたCommand特有のイベントへとキャストして使います。　　今回の場合は　　var e:ClickBtnHelloWorldEvent = event as ClickBtnHelloWorldEvent 　　としてCairngormEventからClickBtnHelloWorldEventへとキャストをしています。 ⑤ApplicationDataModelクラスのインポート　　ApplicationDataModelはデータバインディングのデータの入れ物、器です。　　詳しいことはDataModel層の解説で述べますが、　　データの入れ物ということなので、MXMLでデータを表示する際に使うためインポートしています。 ⑥SamplecairngormHttpDelegateクラスのインポート　　DelegateクラスはHTTPServiceあるいはRemoteObjectと直接連携するために　　設けられたクラスです。　　これはService層で解説しますが、このサンプルではHTTPServicecと連携したいために、　　その連携方法をもつDelegateであるSamplecairngormHttpDelegateをインポートしています。 ⑦public class ClickBtnHelloWorldCommand implements ICommand,IResponder 　　前述のICommand、IResponderを実装したクラスの宣言です。 ⑧executeメソッド　　イベントが送出された際に呼び出される実行メソッドです。　　FrontControllerを継承したクラスの中でaddCommandメソッドを用いて、　　イベントとCommandクラスをマッピングしていますが、　　このイベントが起こった際に呼び出されるメソッドがこのメソッドです。　　またイベントが起こった際にはCairngormEventが渡されてきます。　　多くの場合、自分のCommandクラスに関連付けされたEventへキャストして利用します。　　これは④で、既に述べられています。 ⑨ClickBtnHelloWorldEventクラスへのキャスト　　④、⑧の解説ですべてです。 ⑩HTTPServiceあるいはRemoteObjectとの橋渡し役をするDelegateクラスのインスタンス化　　Delegateクラスの役割は⑥の解説とService層の解説に記述されていますが、　　ここでのポイントはDelegateクラスをインスタンス化するときに、　　new SamplecairngormHttpDelegate(&bold(){this}) 　　と、自分のインスタンスを渡しているところです。　　この自分のインスタンスを渡すことで、自分の持っているメソッドであるresult、faultに　　HTTPServiceやRemoteObjectメソッドの実行結果が返ってくるようになります。　　これはIResponderインターフェースを実装しているからです。 ⑪Delegateのメソッドの呼び出し　　HTTPServiceやRemoteObjectを利用しての呼び出しはすべてDelegateクラスを　　用いて行うこと、というのがCairngormのひとつのルールです。　　このサンプルでもそのルールに従って呼び出しています。 ⑫resultメソッド ⑬ApplicationDataModelのインスタンスの取得 ⑭結果をDataModelへ設定　　⑩にて解説されていますが、Delegateクラスのメソッドを実行したときに、　　その実行が成功した場合に実行されるメソッドです。　　サーバサイドと連携した場合、このメソッドにデータベースの検索結果等が　　返ってきますので、それを用いてロジックを実装していくところです。　　多くの場合、データベースの検索結果などは　　ApplicationDataModelのインスタンスを取得して、　　そのDataModelのプロパティに該当する結果を設定する、といった形になります。 ⑮faultメソッド　　⑩にて解説されていますが、Delegateクラスのメソッドを実行したときに、　　その実行が失敗した場合に実行されるメソッドです。　　HTTP接続エラーなどのエラーハンドリングは、このメソッドで記述していくことが多いのではないでしょうか。３） EventパッケージはFrontControllerクラスを継承したクラスを作る際に public static const SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENT のように静的領域に文字列を宣言していましたよね。その文字列を使って作ったものがEventパッケージの中に入ります。ここでは実際にサンプルアプリケーションのEventクラスを見てみましょう。 package sample.controller.samplecairngorm.event { import com.adobe.cairngorm.control.CairngormEvent;　　　　　･･････････････････････････････・・・・・・・・・・・・・・・① import sample.controller.samplecairngorm.*　　　　　　　　　　　　･･･････････････････････････・・・・・・・・・・・・・・・・・② /** * イベントクラスです */ public class ClickBtnHelloWorldEvent extends CairngormEvent　　　　･･････････････････・・・・・・・・・・・・・・・・・③ { /** * コンストラクタです */ public function ClickBtnHelloWorldEvent(o:Object):void　　　　　･････････････････････・・・・・・・・・・・・・・・④ { // コントローラーに設定した一意に識別するためのイベント名を // superクラスのコンストラクタに渡しています。 // これにより、このイベントはコントローラーに設定した一意の識別名をもつ // イベントとして認識されるようになります。 super(SamplecairngormController.SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENT);　・・・・・・⑤ } } } ①import com.adobe.cairngorm.control.CairngormEvent 　　Eventクラスを作る際には、Cairngormでは必ず、このCairngormEventクラスを継承します。　　その継承のためにインポートをしています。 ② import sample.controller.samplecairngorm.* 　　後で記述が出てきますが、FrontControllerクラスを継承したクラスの中で　　「public static const」と宣言した文字列があると思います。　　その文字列を利用するため、Controllerクラスをインポートしています。 ③public class ClickBtnHelloWorldEvent extends CairngormEvent 　　CairngormEventを継承してEventクラスを宣言しています。 ④ ClickBtnHelloWorldEventコンストラクタ ⑤super(SamplecairngormController.SAMPLECAIRNGORM_BTNHELLOWORLD_CLICK_EVENT) 　　このコンストラクタの中で宣言されている親クラスのコンストラクタを呼び出すsuper（）メソッドの中で、　　②にてインポートしたFrontControllerクラスを継承したクラスの　　「public static const」で宣言した文字列を利用して親のコンストラクタを呼び出しています。　　この親のコンストラクタに渡される文字列が、Cairngormの中で一元管理されるようになります。以上、少し長くなりましたがController層の解説になります。 [[次はDataModel層です。>http://www39.atwiki.jp/flex_framework/pages/24.html]]

Cairngorm_Framework

2008-08-20T16:50:21+09:00

＜Cairngormの批評と図式＞１．Cairngormの批評 |項目名|Cairngorm|批評| |理解しやすさ|◎|イベントを一元管理化しているので、イベントと実行されるロジックが理解しやすいです| |導入しやすさ|○|オープンソースというところから、英語版ではありますがサンプルもあるので、比較的導入が簡単です。| |コーディング量|×|１イベントにつき、１実行ロジックというプログラムになってしまいますので、コーディングの量はどうしても増えてしまいます。| |用意されているクラス郡の使いやすさ|○|下記フローチャートをご覧いただきますとわかりますが、基本的なクラスは多くありません。また役割もはっきりしているので使いやすいと思います。| |テスタビリティ|×|これといったテストの方法がなく、「目視による動作確認テスト」くらいしか有効なテスト手段がありません。| |用意されているドキュメントの量|◎|オープンソースということでサンプルは比較的多いです。ほとんどが英語ですが、サンプルもあるので、わかりやすいと思います。| |サーバー技術との親和性|◎|サーバーとFlexのロジックを分離する、というのもこのフレームワークの目的ですので、サーバサイドの技術を選びません。| |改造のしやすさ|×|１イベントにつき、１実行ロジックということは既に述べましたが、その都合上、どうしても１イベント、複数実行ロジックという改造が難しい点があります（できないわけではありません）。| |保守のしやすさ|○|１イベント、１実行ロジックですので、イベントを見れば実効されているロジックがわかりますので、あちこち見る必要がなく、見やすいプログラムになります。| |知名度|○|Adobe社がオープンソースとしているので、知名度は高いかと。| |導入しやすい案件規模|画面数が～３０くらいまで|１イベント、１実行ロジックという形式をとりますので、画面数が多くなればそれだけイベント、ロジックの数が増えてきます。画面数が増えればイベントが増えるとうことで、イベントが一元管理される、ということはそれだけ管理するイベントが膨大になりますので、それだけで大変になります。| |教育コースが存在するか|×|今のところ私は教育コースは知りません。独自で解釈しています。| ２．Cairngormのフローチャート図 #image(http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=Cairngorm_Framework&file=CairngormFlow.JPG,width=500,height=300,title=cairngormフローチャート) [[元の大きな画像はこちら>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=Cairngorm_Framework&file=CairngormFlow.JPG]] 「フローチャート解説」 View層ではCairngormEventというものを発生させて、それをController層に通知するようになっています。そのEventを受け取ったControllerは１イベント、１実行ロジックという風にマッピングされている実行ロジック（Cairngormの中では Commandと表現しています）を呼び出して、そのコマンドの中で業務ロジックを記述し、データバインドをしているDataModelへデータを渡すようにしています。実際にサンプルを動かしてもらったほうが早いでしょう。 ※サンプルはAdobeAIRで作られています。FlexBuilder3のプロジェクトをアーカイブしたものをサンプルとしておきます。 [[サンプルはこちらから>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=Cairngorm_Framework&file=SampleCairngorm.zip]] 実行していただけるとよりわかりやすいと思います。 [[サンプルの解説はこちらから>http://www39.atwiki.jp/flex_framework/pages/22.html]] **メリット +イベントが一元管理されどのイベントがどのロジックを呼んでいるかすぐにわかる。 +サーバサイドとのやりとりが窓口がＤｅｌｅｇａｔｅになることにより、サーバサイドからの返却がわかりやすい。 **デメリット +画面数が増えるとイベントを管理するＣｏｎｔｒｏｌｌｅｒが煩雑になり、可読性を損なう。 +Ｅｖｅｎｔ、Ｃｏｍｍａｎｄがすべて１対１になるので、イベントの数の２倍のクラス（ＥｖｅｎｔクラスとＣｏｍｍａｎｄクラス）ができてしまう。 #comment(title_name=なまえ：,title_ms=コメント：)

トップページ

2008-08-20T16:46:49+09:00

**Flexのフレームワークを比較検証するため（あるいは布教活動に役立てるため）のサイトです。 -さまざまなフレームワークが登場し、どれがどのようなものなのか、さっぱりっていうことがあると思います。その助けになればと思いまして、作ってみました。 -またページは自由に編集することができます（間違っているところ、解釈が違うところなどはぜひ、修正をお願いします！！） &bold(){注意！！} &bold(){この検証の中で使われているサンプルはすべてFlexBuilder３を使って作ったものです。} &bold(){FlexBuilder２で動かないことがありますので、注意をお願いします。} ---- **Flexのフレームワークの種類 -[[Cairngorm(公式サイト)>http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm/]] &italic(){＜＜概要＞＞} アドビ社のリリースしているオープンソースなフレームワークです。 &bold(){イベント駆動型なFlexのいろいろなイベントと、そのイベントが起きたときに実行されるロジックとをマッピングすることにより、イベントを一元管理するようにしたものです。} Controller層、DataModel層、View層に分かれるため、MVCモデルのように構築することができます。ただしDataModel層はデータをバインディングするための器という機能しかもっていません。実際のビジネスロジックはController層に入ることでしょう。 -[[PureMVC(公式サイト)>http://puremvc.org//]] &italic(){＜＜概要＞＞} Cairngormを元としていますので、イベントを一元管理化する、という基本コンセプトは同様です。しかし、Cairngormは１つのアプリケーションすべてのイベントを一元管理する、ということに対して画面ごとに「&bold(){その画面で起きるイベントはその画面に管理してもらおう}」といった趣旨のもと、構築されています。 Controller層、Model層、View層に分かれるため、MVCモデルのように構築することができます。 Cairngormとの大きな違いはModel層にあります。 CairngormではModel層はデータの入れ物だっただけに対し、 PureMVCではビジネスロジックを記述できるようになりました。 -[[Mate(公式サイト)>http://mate.asfusion.com/]] &italic(){＜＜概要＞＞} できるだけActionScriptレスなプログラムを目指して作られたフレームワークです。大きな特徴としてはやはり&bold(){MXML主体でプログラムを書いていくこと}です。 ActionScriptを利用する機会はカスタムイベントを作るときくらいではないでしょうか。 MateではMXMLで発生するイベントをEventMapというMXMLでマッピングを行います。このMXMLで発生するイベントというのがカスタムイベントになります。カスタムイベントを送出するロジックすらMXMLで記述されています。 ※2008/8/18時点のpublic alpha版を対象としています。 -[[YUI-Framework(公式サイト)>http://akabana.sandbox.seasar.org/ja/products/yui/index.html]] &italic(){＜＜概要＞＞} YuiApplicationという独自のタグを用いることで、View層とLogic層の完全分離を目指しています。 &bold(){YuiApplicationタグで書かれたMXMLファイルに記述されるUIComponentのタグはIDプロパティを設定するのみで、} &bold(){イベントハンドラ（たとえばclickなど）を書く必要がありません。} YuiApplicationタグで実装されたMXMLはすべてLogic層にあるLogic用のActionScriptと連携するようにできているからです。ですので、MXMLの中にはActionScriptを書くことがなく、イベントすら設定する必要がありません。 MXMLの中にUIComponentを配置していくだけでMXMLファイルはView層を実装したことになります。よってデザイナーがレイアウトを作り、プログラマがロジックを実装する、というような分業ができます。 ※2007/7/28リリース時点のpublic Alpha版を対象としています -[[ASWing(公式サイト)>http://www.aswing.org/]] &italic(){＜＜概要＞＞} GUIBuilderを実装しているようで、それを利用してMXMLを作れるみたいです。 ActionScript2.0用と3.0用のフレームワークが公開されています。（未検証） ---- [[フレームワークの比較検証へ>http://www39.atwiki.jp/flex_framework/pages/16.html]] - コメントテスト -- AKIRA (2008-08-20 10:03:25) #comment(title_name=なまえ：,title_ms=コメント：)

Cairngormサンプル解説(完

2008-08-20T16:45:28+09:00

Cairngormの解説もいよいよ今回で最後になります。 View層の解説です。 View層は以下のように構成されています。１）viewパッケージ２）helperパッケージ今回のサンプルでは１）viewパッケージには何もないと思います。 SampleCairngorm.mxmlをそのままviewとして利用しているためです。一般的に、ViewStackやStateで別コンポーネント化したものがこのviewパッケージに入れる、とお考えください。 SampleCairngorm.mxmlの解説は [[Cairngormサンプル解説(1>http://www39.atwiki.jp/flex_framework/pages/22.html]] にて解説しておりますので、そちらを参照ください。ここでは２）helperパッケージについて解説します。２） helperパッケージは &bold(){「View層の画面表示用MXMLのScript部分をそのまま集めたクラスをViewHelperと呼ぶようにした」} といえるのではないでしょうか。 Cairngormの根本的な考え方として &bold(){「ScriptタグはMXMLの中にはできるだけ書かないようにしよう」 } というのがありましたよね。 MXMLの中でScriptで書いていたものがこのhelperパッケージで設定されるViewHelperクラスになります。このViewHelperクラスはViewHelperというクラスを継承したクラスはCairngormの中で一元管理されます。一元管理されるということなので、 &bold(){「ViewHelperにはユニークなIDを割り当てなければならない」} ことに気をつけてください。サンプルのSampleCairngorm.mxmlの中ではと宣言されています。ここで指定したIDがCairngormの中で（つまりは１つのFlexプロジェクトの中で）ユニークになっていなければなりません。実際に見てみましょう。例えばサンプルプロジェクトに「Test1.mxml」というMXMLコンポーネントを作成し以下のように記述します。そしてこの「Test1.mxml」を「SampleCairngorm.mxml」に追加してみましょう。例）SampleCairngorm.mxmlの一部　　　　　　　　　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　　　・ &bold(){} これをコンパイルしてみましょう。コンパイルは無事に通るかと思いますが、実行してみるとエラーが発生するはずです。それは &bold(){「sampleViewHelperという名前は既に使われているので、名前を変えてください」} といった意味のエラーが出るはずです。このようにViewHelperのIDは必ずユニークでなければいけません。さて、肝心のViewHelperクラスの中身ですが package sample.view.samplecairngorm.helper { import com.adobe.cairngorm.view.ViewHelper; import com.adobe.cairngorm.control.CairngormEventDispatcher;　　　　　　　　　　　　　　　・・・・・・・・・・・・・① import flash.events.*; import sample.controller.samplecairngorm.event.ClickBtnHelloWorldEvent;　　　　　　　･･････････････② /** * Samplecairngorm画面用のViewHelperです。 */ public class SamplecairngormViewHelper extends ViewHelper　　　　　　　　　　　　　　　･･･・・・・・・・・・・・・・・・③ { public function SamplecairngormViewHelper() { super(); } /** * Samplecairngorm画面のボタンID「btn」というUIコンポーネントの * clickイベントをハンドルするためのメソッドです。 */ public function clickBtnHelloWorld(event:MouseEvent):void { // ここでは単純にイベントをDispatchしていますが、 // この中でVaridationを行うこともできます。 // またViewHelperクラスは「view」というプロパティを持っていて、 // このViewというプロパティはViewHelperクラスをインスタンス化した際の // MXMLのインスタンスを示しています。 // このプログラムで「View」プロパティが示すMXMLのインスタンスは // 「SampleCairngorm.mxml」のインスタンスです。 // MXMLのインスタンスですので、そのMXMLに書いてあるUIコンポーネントのインスタンスを取得することもできます。 // 例） // SampleCairngorm.mxmlのLabelのインスタンスを取得し、textプロパティを取得したい // var str:String = SampleCairngorm(view).lbl.text; // こんな風に直接、Viewから値を取得することも可能です。 CairngormEventDispatcher.getInstance().dispatchEvent(new ClickBtnHelloWorldEvent(new Object()));　　･･･④ } } } ① CairngormEventDispatcherのインポート　　CairngormEventDispatcherというのは　　&bold(){「Cairngormがイベントとして認識するものを送出するためのクラス」} 　　です。　　このクラスを利用してイベントを送出しなければ、　　FrontControllerクラスを継承したControllerクラスはイベントを受け取ってくれませんし、　　イベントにマッピングされたロジックも実行されませんので、注意が必要です。　　 ② ClickBtnHelloWorldEventのインポート　　FrontControllerクラスを継承したControllerクラスでpublic static constに設定したイベント文字列を持つイベントをインポートしています。　　これがCairngormEventになるわけです。 ③ ViewHelperを継承したSamplecairngormViewHelperクラスの宣言　　CairngormにViewHelperクラスとして認識させるために、ViewHelperクラスを継承したクラス宣言を行っています。 ④CairngormEventDispatcher.getInstance().dispatchEventメソッドを使ってのイベント送出　　このメソッドを発行することにより、　　&bold(){「FrontControllerクラスを継承したクラスでaddCommandしたCommandクラスを呼び出す」} 　　ことをしています。　　このことにより、該当するイベントにマッピングされたCommandクラスのｅｘｅｃｕｔｅメソッドが呼び出されるわけです。以上がＶｉｅｗ層の解説でした。以上でＣａｉｒｎｇｏｒｍの解説は終了です。ここまで長々と書いてきましたが、いかがでしたでしょうか？サンプルのプロジェクトをダウンロードして動かしたほうが早いかもしれませんが、ＰｕｒｅＭＶＣも解説していたのでこちらも解説をつけました。

メニュー

2008-08-20T16:18:28+09:00

**メニュー -[[トップページ]] -[[フレームワークの比較検証>http://www39.atwiki.jp/flex_framework/pages/16.html]] -[[Cairngorm>http://www39.atwiki.jp/flex_framework/pages/12.html]] +[[Cairngormサンプル解説(1>http://www39.atwiki.jp/flex_framework/pages/22.html]] +[[Cairngormサンプル解説(2>http://www39.atwiki.jp/flex_framework/pages/23.html]] +[[Cairngormサンプル解説(3>http://www39.atwiki.jp/flex_framework/pages/24.html]] +[[Cairngormサンプル解説(4>http://www39.atwiki.jp/flex_framework/pages/25.html]] +[[Cairngormサンプル解説(完>http://www39.atwiki.jp/flex_framework/pages/26.html]] -[[PureMVC>http://www39.atwiki.jp/flex_framework/pages/13.html]] +[[PureMVCサンプル解説（1>http://www39.atwiki.jp/flex_framework/pages/18.html]] +[[PureMVCサンプル解説（2>http://www39.atwiki.jp/flex_framework/pages/19.html]] +[[PureMVCサンプル解説（3>http://www39.atwiki.jp/flex_framework/pages/20.html]] +[[PureMVCサンプル解説（完>http://www39.atwiki.jp/flex_framework/pages/21.html]] -[[Mate>http://www39.atwiki.jp/flex_framework/pages/14.html]] -[[YUI-Framework>http://www39.atwiki.jp/flex_framework/pages/15.html]] ---- **リンク -[[@wiki>>http://atwiki.jp]] -[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] -[[よくある質問>http://atwiki.jp/guide/category1.html]] **分からないことは？ -[[@wikiへのお問合せフォーム>http://atwiki.jp/helpdesk]] **管理人に連絡 [[連絡フォーム>http://www39.atwiki.jp/flex_framework/pages/17.html]] //**更新履歴 //#recent(20) &link_editmenu(text=ここを編集)

Cairngormサンプル解説(4

2008-08-20T16:17:55+09:00

Service層の解説です。この層では１）Serviceパッケージ２）Delegateクラスで構成されています。１） Serviceパッケージに配置されるクラスは ServiceLocatorタグを持ったMXMLである ApplicationService.mxmlのみです。これはCairngormがHTTPServiceやRemoteObjectといった &bold(){「サーバサイドとの連携の入り口を１つにしてしまおう」} との意図があります。サーバサイドとの連携はＨＴＴＰＳｅｒｖｉｃｅやRemoteObjectを利用しますが、それらを管理しているのが、このApplicationService.mxmlファイルです。中身を見て見ましょう。タグのIDが一致しないと、 * HTTPServiceのインスタンスは取得できませんので気をつけてください。 **/ public static const APPLICATION_HTTP_SERVICE_NAME:String = "appHttpService";　　　　････② ]]> ①ServiceLocatorタグ　　③にて記述されるHTTPServiceをCairngormが管理するために用意されたタグが　　このServiceLocatorです。　　このタグの中で宣言されたHTTPServiceやRemoteObjectタグは　　ServiceLocatorクラスより取り出すことができます。　　例）　　var httpSrv:HTTPService =　ServiceLocator.getInstance().getHTTPService("appHttpService"); ②public static const APPLICATION_HTTP_SERVICE_NAME 　　ここで宣言されているpublic static constの文字列は　　③で記述されているHTTPServiceタグ（あるいはRemoteObjectタグ）のIDの文字列と　　一緒である場合が必要です。　　上記①で記したようにServiceLocatorからHTTPServiceあるいはRemoteObjectを取り出す際に、　　ServiceLocatorタグの中で宣言したHTTPServiceタグ（あるいはRemoteObjectタグ）のIDを用いて、　　ServiceLocatorタグから取り出すからです。　　このIDは外部からのアクセス（例えばDelegateクラスからのアクセス）ではIDを　　取得することが難しいです。　　しかし、public static constとして宣言しておけば、　　わざわざタグのIDを調べなくても、この宣言を利用するだけで取り出せるようになるからです。　　ですので、必ず宣言しましょう。 ③HTTPServiceタグ　　HTTPServiceを行うタグです。　　resultにはevent.token.resultHandler(event) 　　faultにはevent.token.faultHandler(event) 　　と指定されていますが、これはDelegateの中で使う際に指定するもので、　　IResponderのresultメソッドとfaultメソッドがそれぞれ関連付けされるようになっています。　　詳しくはDelegateの解説をご覧ください。２） DelegateクラスはHTTPServiceやRemoteObｊｅｃｔ等、サーバサイドと連携を行うためのクラスです。Ｃａｉｒｎｇｏｒｍではこの &bold(){「Ｄｅｌｅｇａｔe以外ではサーバサイドとの連携ロジックは組み込まない」} というルールになっています。では、サンプルのDelegateクラスを見てみましょう。 package sample.service.samplecairngorm { import mx.rpc.IResponder; import mx.rpc.http.HTTPService; import com.adobe.cairngorm.business.ServiceLocator;　　　　　　　　　　　　　　　　　　　　　　　･･････・・・・・・・・・・・・・・・① import sample.service.ApplicationService; /** * サーバと連携するためのクラスです。 */ public class SamplecairngormHttpDelegate { private var _responder:IResponder; private var _httpService:HTTPService; /** * コンストラクタです。 * @param callingCommand サービス実行結果を返却する先を示すオブジェクトIResponderです。 */ public function SamplecairngormHttpDelegate(callingCommand:IResponder)　　　･･･････････････・・・・・・・・・・・・・・・② { // ApplicationServicecからHTTPServiceのインスタンスを取得します。 _httpService = ServiceLocator.getInstance().getHTTPService(ApplicationService.APPLICATION_HTTP_SERVICE_NAME); // 返却オブジェクトを保持します。 _responder = callingCommand;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　････････････・・・・・・・・・・・・・・・・・③ } /** * Commandクラスから呼び出されるサーバ連携用メソッドです。 * @param o サーバーに渡したい値などを入れたObjectクラスです。 */ public function clickBtnHelloWorld(o:Object):void　　　　　　　　　　　　　　　　　　　　　･････････・・・・・・・・・・・・・・・・・④ { // 返却オブジェクトのTOKENを指定するため、一時的にObject型に変換しています。 var service:Object = _httpService; // URLを指定します。 _httpService.url = "./hello.xml"; // アクセスした結果をserviceに返却し、そのserviceのresultHandlerとfaultHandlerのtokenに設定します。 service = _httpService.send(); service.resultHandler = _responder.result; service.faultHandler = _responder.fault;　　　　　　　　　　　　　　　　　　　････････････・・・・・・・・・・・・・・・・⑤ } } } ①インポート文　　Delegateクラスでは、サーバサイドとの連携結果を返すためのオブジェクト設定のためにＩＲｅｓｐｏｎｄｅｒを、　　サーバサイドとの連携をするためのクラス保持のためにHTTPService（あるいはRemoteObject）クラスを　　そしてCairngormの中で管理されたHTTPServiceあるいはRemoteObjectを取得するためにServiceLocatorクラスを　　それぞれインポートしています。 ②コンストラクタ　　コンストラクタの引数としてIResponderを受け取っていますが、　　これはHTTPServiceやRemoteObjectのメソッドを実行した結果を返すオブジェクトを　　設定するためです。　　このIResponderに指定されたresultメソッドあるいはｆａｕｌｔメソッドに　　サーバサイドの実行結果が返却されるようになっています。 ③サーバサイド連携オブジェクトの取り出しと返却オブジェクトの設定　　ＳｅｒｖｉｃｅＬｏｃａｔｏｒからHTTPServiceあるいはRemoteObjectを取り出しています。　　また引数として受け取ったcallingCommandを　　インスタンス変数に設定しています。　　このことにより、サーバサイドのサービス実行結果がcallingCommandのresultメソッドあるいはfaultメソッドに　　返却されるようになります。 ④サーバサイド連携メソッド　　実際にサーバサイドと連携するためのメソッドです。　　Commandのexecuteメソッドの中でこのメソッドが呼び出されることでしょう。　　引数として渡されているObjectクラスは　　HTTPServiceやRemoteObjectに渡すリクエストのパラメータを持ったObjectです。　　例として　　_httpService.request = o; 　　と使えると思います。 ⑤返却先の再設定　　実際に取り出されたHTTPServiceあるいはRemoteObjectの結果ハンドラを設定しているのがこの部分です。　　service.resultHandler = _responder.result; 　　service.faultHandler = _responder.fault; 　　とサービスオブジェクトのそれぞれのハンドラに設定していることがわかります。 ※サーバサイド連携メソッドの中でプログラムで意識しなければいけないところは　　service.url 　　か　　service.request 　　のどちらかになります（HTTPServiceの場合）　　それ以外のコーディングはお約束として必ず記述をしてください。　　そうでないとうまくIResponderに返却されません。以上がService層の解説です。 Service層もDelegateが少々、特殊なことをしていますが、ここはひとつお約束の構文ということで。 [[次は最後のView層の解説になります。>http://www39.atwiki.jp/flex_framework/pages/26.html]]

Cairngormサンプル解説(3

2008-08-20T15:43:57+09:00

さて、ここではサンプルソースにあるDataModel層について解説します。といっても、ここはあまり難しくありません。この層はビジネスロジックの入る余地がなく、 DataModelは単に &bold(){「MXMLにデータバインディングするためのデータの入れ物」} でしか、ないからです。このあたりもCairngorm特有のものではないでしょうか。以下のように構成されています。１）ApplicationDataModelクラス２）画面固有のDataModelクラスここではDataModelパッケージにある２つのクラスを見てみましょう。１） Cairngormで唯一、静的な領域にデータをもつDataModelがこのApplicationDataModelです。 package sample.datamodel { import sample.datamodel.samplecairngorm.SamplecairngormDataModel; /** * View層のデータバインディングのためのデータの器であるDataModelクラスです。 */ [Bindable] public class ApplicationDataModel { /** * デフォルトコンストラクタです * ただし、このコンストラクタを利用しての外部からの * インスタンス化は認めてはいけません。 * 「static」で宣言されているgetInstanceメソッドの中でのみ、 * このコンストラクタを呼ぶようにします。 */ public function ApplicationDataModel()　　　　　　　　　　　　　　　　　　　　　･･･････････････・・・・・・・・・・・・・・・・・① { _sampleModel = new SamplecairngormDataModel(); } // ここでは「static」な領域に自分のインスタンスを持つようにしています。 // Flexでは基本的にAというMXMLとBというMXMLとの値のやりとりは不可能に近いです。 // これを有効にするために「静的」な領域にデータの器であるDataModelをもつことにより、 // AとBとのやりとりを可能にしています。 private static var _model:ApplicationDataModel; /** * 「static」な領域にある自分のインスタンスを取得します。 * インスタンスがない場合はインスタンス化して、そのインスタンスを返却します。 * @return ApplicationDataModel データバインディングモデル */ public static function getInstance():ApplicationDataModel　　　　　　･･･････････････・・・・・・・・・・・・・・・・・② { if( _model == null ) { _model = new ApplicationDataModel(); } return _model; } // 画面固有のデータバインディングのためのDataModelクラスを定義しています。 // View層に配置されるMXMLファイルの数に応じて、このDataModelを増やしていくほうが // わかりやすいと思われます。 private var _sampleModel:SamplecairngormDataModel;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・③ public function get sampleModel():SamplecairngormDataModel { return _sampleModel; } public function set sampleModel(model:SamplecairngormDataModel):void { _sampleModel = model; } } } ①コンストラクタ　　クラス宣言のところに[Bindable]の宣言が書いてあるので、　　このクラスはデータバインディング用のクラスある、と言えるのですが、　　このコンストラクタは利用しないようにしてgetIsntace()メソッドを用意しているのが特徴です。　　これはCairngormがMXMLとMXMLとの間（あるいはMXMLとActionScriptの間）のデータのやりとりを　　基本的に静的なデータ領域にデータをおいて、そのデータの領域を用いてやりとりを行うようにしているからです。　　ですので、このコンストラクタを用いて、ApplicationDataModelのインスタンス化を許してしまうと、　　静的な領域にDataModelは作成されません。　　③にある画面固有のDataModelのインスタンス化のタイミングがないために、このコンストラクタが記述されていますが、　　Cairngormでは使われないコンストラクタになります。 ②public static function getInstance():ApplicationDataModel 　　①に述べたように静的な領域にデータを持たせたいがために、　　DataModelを使いたいクラスはこのgetInstanceメソッドを用いて、　　ApplicationDataModelのインスタンスを取得するようにしています。 ③View層にあるMXML専用のDataModelのプロパティ　　サンプルのようにMXMLが１画面しかないような場合には、ApplicationDataModelクラスだけあればよいのですが、　　複数の画面になると、ApplicationDataModelクラスひとつでやっていくと、どうしても大きくなってしまいます。　　そこで各々のMXML専用にDataModelを作成し、ApplicationDataModelでプロパティとしてもつようにすれば、　　少なくとも、ApplicationDataModelが煩雑になるのを防ぐことができます。２） MXML専用のDataModelです。今回のサンプルではHelloと返すためにｔｘｔFieldというプロパティしか実装されていませんが、画面の数が増えればそれだけ、ここにい上げたMXML専用のDataModelが増えていくのではないでしょうか。 package sample.datamodel.samplecairngorm { [Bindable] public class SamplecairngormDataModel { public function SamplecairngormDataModel() { txtField = ""; } public var txtField:String; } } Controller層に比べ、やっていることはデータバインディングのための器でしかないDataModel層。役割がはっきりしている分、わかりやすいのではないでしょうか。 [[次はService層の解説です。>http://www39.atwiki.jp/flex_framework/pages/25.html]]

Cairngormフレームワーク解説1

2008-08-20T13:51:49+09:00

ここではサンプルソースの解説を行います。サンプルソースはボタンを押したら、「HelloWorld」と文字列が返ってきて、それが画面に表示されるという簡単なものです。それらのCairngormのソース構成を１．controller ２．dataModel ３．service ４．view と分けて解説していきます。まず最初のFlexアプリケーションのスタートファイルに当たる「SampleCairngorm.mxml」を見ていきましょう。 &bold(){※サンプルソースはAIRを用いて作られています。} &bold(){ですのでスタートタグが「mx:Application」ではなく「mx:WindowedApplication」となっていますが、} &bold(){振る舞いは変わりません。} &bold(){サーバサイドのFlexアプリケーションを作成するときはこの「mx:WindowedApplication」を} &bold(){「mx:Application」に変更してください。} ･･････････････････････････････・・・・・・・・・・・・・・・① 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　･･･････････････････････････・・・・・・・・・・・・・・・・・② 　　･･･････････････････････････・・・・・・・・・・・・・・・・③ 　　　　　　　　　　　　　　　　　　　　　･･･････････････・・・・・・・・・・・・・・・・・・・・④ ････････････・・・・・・・・・・・・・・・・・⑤ ･･･････････････････････････････････････････⑥ ・・・・・⑦ ①Applicationタグ　　このタグは説明するまでもなく、Flexアプリケーションのスタートには必ず必要なタグですね。　　このタグの中のプロパティとして注目すべきは以下の点です。　　　　１）xmlns:ctrl="sample.controller.samplecairngorm.*" 　　　　Controller層のインスタンス化をするためにこの一文が必要になります。　　　　Controller層については後で解説していきますが、　　　　&bold(){CairngormのController層はイベントマッピングをするためのもので、} 　　　　&bold(){必ずインスタンス化が必要になる} 　　　　と考えてください。　　２）xmlns:srv="sample.service.*" 　　　　Service層のインスタンス化をするためにこの一文が必要になります。　　　　Service層ではサーバーとの連携部分を担っており、ここでインスタンス化されたServiceが　　　　Cairngormのソースの中で使いまわされています。　　　　Service層については後で解説していきますので　　　　とりあえず、これもController層と同様に　　　　&bold(){必ずインスタンス化が必要になる} 　　　　と考えてください。　　３）xmlns:viewhelper="sample.view.samplecairngorm.helper.*" 　　　　View層のロジックを肩代わりするための役目をもつ「ViewHelper」というクラスを　　　　インスタンス化するためにこの一文が必要になります。　　　　CairngormではMXMLファイルの中にはできるだけ、「mx:Script」というタグは書かないようにと、　　　　考えられています。　　　　ではScriptタグを書かずにどこにスクリプトを記述していくのか？　　　　その答えがこのViewHelperクラスになります。　　　　View層についても後に解説していきますので、　　　　Controller層、Service層と同様に　　　　&bold(){必ずインスタンス化が必要になる} 　　　　と考えてください。 ②Scriptタグ　　Cairngormでは「ScriptタグはMXMLの中にはできるだけ書かないようにしよう」　　という考えのもと、作られたフレームワークですが、　　唯一の例外がこの [Bindable] private var _model:ApplicationDataModel = ApplicationDataModel.getInstance(); 　　でしょう。　　ここではデータモデルのインスタンスを取得しています。　　DataModel層については後に解説しますが、　　Cairngormの中でいうDataModelというのは　　「データバインディングのためにデータを入れるための器」　　と考えてください。　　ですので、[Bindable]で宣言し、インスタンスを取得しているのです。　　またなぜnew演算子ではなくgetInstance()メソッドを利用してインスタンスを取得してるかも、　　DataModel層の解説で説明します。　　今のところはデータの器をインスタンス化したと考えてください。 ③Controllerのインスタンス化　　Controller層のControllerをここでインスタンス化しています。　　Controllerはイベントとロジックをマッピングしてくれるものです。　　よって、このFlexのスタートを示すApplicationタグの中に、　　このController層のインスタンス化がされていないと、　　イベントが発生しても、ハンドルされません。　　つまり、イベントが起きても、プログラムは何もしないことになります。　　ですので、Controller層のインスタンス化は必ず必要になります。 ④Serviceのインスタンス化　　Service層のApplicationServiceというクラスをインスタンス化しています。　　ApplicationServiceというのはHTTPServiceタグあるいはRemoteObjectタグを持っただけの　　MXMLなのですが、このApplicationServiceというのは　　Cairngormの中でServiceLocatorというクラスで管理します。　　ここでインスタンス化をしているのは以下の理由からです。　　・ServiceLocatorにHTTPServiceまたはRemoteObjectを登録するため　　・HTTPServiceあるいはRemoteObjectをCairngormの中で使いまわしていくため　　つまり、これもControllerと同様にFlexのスタートを示すApplicationタグの中に、　　インスタンス化しないといけないものになります。 ⑤ViewHelperのインスタンス化　　Cairngormでは「ScriptタグはMXMLの中にはできるだけ書かないようにしよう」　　という考えのもと、作られているのですが、　　ではScriptがどこに書かれているのか、というと、　　ここでインスタンス化しているViewHelperです。　　ViewHelperというクラスはMXMLの１つのファイルにつき、１つ以上存在します。　　ActionScriptを書かなければならないのですから、当然ですよね。　　でも、それならなぜ、普通のClassではなく、ViewHelperなのでしょうか？　　これもView層の部分で解説しますが、　　CairngormではView層の画面表示部分であるMXMLファイルと　　View層のロジック部分であるViewHelperクラスを一元管理しているからです。　　ですので、その一元管理をするためにViewHelperクラスを使っているということです。 ⑥Labeｌフィールド　　sayHelloボタンを押したときに「Hello」と返ってくる文字列を入れるためのLabelです。 ⑦Buttonコンポーネント　　sayHelloボタンです。　　このボタンを押すことで、「Hello」と文字列が返ってくるわけですが、　　このボタンのイベント、「click」に注目してください。　　前述⑤にてインスタンス化したViewHelperのクラスのメソッド「clickBtnHelloWorld」を　　呼び出していますよね。　　こうすることで、MXMLの中のScriptタグにロジックを書くのではなく、　　ViewHelperクラスのメソッドにロジックを書いていくことにより、　　画面表示であるMXMLとロジック実行の役割を持つViewHelperに分割しているのです。さて、ここまででFlexのスタートファイルであるApplicationタグをもつMXMLファイルの解説は終わりです。いくつか「&bold(){必ずインスタンス化しなければならない}」という約束事が出てきましたが、全体としてタグを並べているだけですので、わかりやすいのではないでしょうか。 [[次はCairngormの核となるController層について解説します。>http://www39.atwiki.jp/flex_framework/pages/23.html]]

PureMVCサンプル解説４

2008-08-20T11:56:08+09:00

[[PureMVC]]の表現領域であるView層について記述していきます。この層で利用されるクラスは以下の通りです。・ MXML ・ Mediatorクラスこれらについても概要は既に述べていますので、サンプルを見てみましょう。まずはMXMLファイルからです。このMXMLファイルは先に記述したMXMLファイルの中ではなく、 Viewコンポーネントとして作成したMXMLファイルです。先に記述されたMXMLファイルの解説の中の⑤にあたります。「CalclationPanel.mxml」　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・② [Event('click1')] [Event('click2')] [Event('click3')] [Event('click4')] [Event('click5')] [Event('click6')] [Event('click7')] [Event('click8')] [Event('click9')] [Event('click0')] [Event('clickPlus')] [Event('clickMinus')] [Event('clickEqual')] [Event('clickClear')] 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・⑦ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・⑧ ① Panelタグこのタグも説明の必要はないでしょう。 Flexのパネルタグです。このタグのプロパティとして注目すべきは以下の点です。・ layout="vertical" 　　　レイアウトについてです。　　　Verticalの設定なので「縦並び」ということですね。　　　取り立てて、大きく扱うプロパティではないのですが、Absorute（絶対位置）では都合が悪かったので、Verticalにしてみました。・ width="400" height="300" このコンポーネントの大きさです。縦４００ピクセル、横３００ピクセルです。・ creationComplete="{this.init()}" 　　 ② Metadataタグこのコンポーネントがもつイベントのすべてを記述しています。このタグの中に宣言することにより、このコンポーネントが当該イベントを送出することができるようになります。ここでは各ボタンに対応するイベントを設定しました。ボタン１を押したら「click1」イベントが起きるということです。このイベントに対応するハンドラは次に出てくるMediatorクラスでハンドルされます。 ③ public static const click1:String = "click1"; イベントの名称です。 Metadataタグの中で記述されたイベント名をすべてpublic static constとして宣言し、送出されたイベント名を特定できるようにしています。単純にいえば public static const click1 = [Event('click1')] という意味です。これは後述される⑧とMediatorクラスで利用されています。 ④ public var calcVO:CalclationVO; このクラスが保持するインスタンス変数の宣言です。 VOとあるとおり、前回にありましたValueObjectのことで、ここでは計算結果を表示するためのBindableな変数として扱っています。このクラスもまた、Mediatorクラスに出てきます。 ⑤ creationComplete時に呼び出される初期化メソッドここでは「init」としていますが、functionの名称は何でもOKです（初期化を示す単語であれば尚良しです）。ここで重要なのは次の④のことを実行することです。 ⑥ calcVO = new CalclationVO(); 　　インスタンス変数であるcalcVOをインスタンス化しています。　　ここでインスタンス化しないとこのcalcVO変数は永遠にインスタンス化されません（誰がインスタンス化していいのかわからない）ので。　　 ⑦ TextInputコンポーネントです。ここではeditableプロパティをfalseとすることで、ユーザー入力をしないようにしています。計算機なので、直接入力してもらうと何かと不便なので、こうしています。またtextプロパティではインスタンス変数であるcalcVOのcalcStringというプロパティを参照しています。ここで参照することにより、calcVOのcalcStringプロパティの中身がTextInputコンポーネントに表示されるわけです。 ⑧ Buttonコンポーネントです。いわゆるイベントを送出するためのものですね。ご覧のようにclickイベントでは dispatchEvent(new Event( click1 ) ) としてclick1というイベントを送出しています。これは②で述べたMetadataタグの中で指定している [Event('click1')] と関連付けされ、このCalclationPanel.mxmlという ViewコンポーネントはMetadataタグに指定されたイベントを発生させるということがわかるでしょう。さて、ここまでではMXMLファイルの解説（いわゆるViewコンポーネント）の解説をしてきました。このMXMLが画面上に表示される直接的なインターフェースを表していることになります。そして、このMXMLにMetadataとしてイベントが記述されていることがわかるでしょう。 CairngormではイベントはすべてFrontController（ApplicationController）と呼ばれている部分に集中していました。 MXMLの中でMetadataタグを使ってのイベント記述は一切なく、すべてがFrontControllerに集中していたわけです。集中管理できるのは利点ですが、どのViewがどんなイベントを起こしているのかわからなくなってしまうことが多く、この点を改善したのがPureMVCといえるのではないでしょうか。 MXMLを見ればそのコンポーネントがどんなイベントを起こすのかすぐにわかるというのは大きな利点ですね。次にMediatorクラスです。「CalclationPanelMediator.as」 package example.view { import org.puremvc.patterns.mediator.Mediator; import org.puremvc.interfaces.INotification; import org.puremvc.interfaces.IMediator; import example.model.CalclationProxy; import example.view.components.CalclationPanel; import flash.events.Event; import example.ApplicationFacade; import example.model.vo.CalclationVO; public class CalclationPanelMediator extends Mediator implements IMediator　　　　・・・・・・・・・・・・・・・・・・① { private var proxy:CalclationProxy;　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・② public static const NAME:String = "CalclationPanelMediator";　　　　　　・・・・・・・・・・・・・・・・・・③ /** * コンストラクタ * ここではこのMediatorクラスで発生するイベントのリスナを登録 */ public function CalclationPanelMediator(view:Object):void　　　　　　　　・・・・・・・・・・・・・・・・・④ { // 親クラスのコンストラクタの呼び出し super(view);　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・⑤ // ハンドラの登録 calclationForm.addEventListener(CalclationPanel.click0,onClick);　　　・・・・・・・・・・・・・・・・・⑥ calclationForm.addEventListener(CalclationPanel.click1,onClick); calclationForm.addEventListener(CalclationPanel.click2,onClick); calclationForm.addEventListener(CalclationPanel.click3,onClick); calclationForm.addEventListener(CalclationPanel.click4,onClick); calclationForm.addEventListener(CalclationPanel.click5,onClick); calclationForm.addEventListener(CalclationPanel.click6,onClick); calclationForm.addEventListener(CalclationPanel.click7,onClick); calclationForm.addEventListener(CalclationPanel.click8,onClick); calclationForm.addEventListener(CalclationPanel.click9,onClick); calclationForm.addEventListener(CalclationPanel.clickMinus,onClick); calclationForm.addEventListener(CalclationPanel.clickPlus,onClick); calclationForm.addEventListener(CalclationPanel.clickClear,onClick); calclationForm.addEventListener(CalclationPanel.clickEqual,onClick); // facadeインスタンスに登録されたproxyクラス（ロジック実装クラス）を取得 proxy = facade.retrieveProxy( CalclationProxy.NAME ) as CalclationProxy;　　　　・・・・・・・・・・・・・・⑦ } /** * プロパティアクセサ */ public function get calclationForm():CalclationPanel　　　　　　　　　　　・・・・・・・・・・・・・・・・⑧ { return viewComponent as CalclationPanel;　　　　　　　　　　　　　　　・・・・・・・・・・・・・⑨ } /** * イベントハンドラ * ここではCalclationPanelのイベントであるclick0などの * イベントを解析している */ private function onClick(e:Event):void　　　　　　　　　　　　　　　・・・・・・・・・・・・・・10 { // VIEWコンポーネント（プロパティアクセサ）からVOを取得 var calc:CalclationVO = calclationForm.calcVO;　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・11 // イベントタイプにより処理の振り分け switch( e.type )　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・12 { case CalclationPanel.click0:　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・13 proxy.setNumber("0");　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・14 sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc);　　　　　・・・・・・・・・・・・15 break; case CalclationPanel.click1: proxy.setNumber("1"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click2: proxy.setNumber("2"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click3: proxy.setNumber("3"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click4: proxy.setNumber("4"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click5: proxy.setNumber("5"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click6: proxy.setNumber("6"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click7: proxy.setNumber("7"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click8: proxy.setNumber("8"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.click9: proxy.setNumber("9"); sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); break; case CalclationPanel.clickMinus: sendNotification(ApplicationFacade.APP_MINUS_CLICK, calc); break; case CalclationPanel.clickPlus: sendNotification(ApplicationFacade.APP_PLUS_CLICK, calc); break; case CalclationPanel.clickClear: sendNotification(ApplicationFacade.APP_CLEAR_CLICK, calc); break; case CalclationPanel.clickEqual: sendNotification(ApplicationFacade.APP_EQUAL_CLICK, calc); break; } } /** * このMediatorクラスで発生するイベントの登録をする */ override public function listNotificationInterests():Array　　　　　　　　　　　・・・・・・・・・・・・・・16 { // ここに列挙された文字列をこのクラスの中ではハンドルすることにより、 // 処理の振り分けを行う。 return [　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・17 ApplicationFacade.APP_NUMBER_CLICK, ApplicationFacade.APP_PLUS_CLICK, ApplicationFacade.APP_MINUS_CLICK, ApplicationFacade.APP_CLEAR_CLICK, ApplicationFacade.APP_EQUAL_CLICK ]; } /** * listNotificationInterestsメソッドで登録された文字列を * 実際に処理に振り分ける */ override public function handleNotification(notification:INotification):void　　　　・・・・・・・・・・・・・・・・18 { switch ( notification.getName() )　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・19 { case ApplicationFacade.APP_NUMBER_CLICK:　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・20 // 画面に表示している情報（VO）の取得 calclationForm.calcVO = notification.getBody() as CalclationVO;　　 // 画面に表示している情報の書き換え calclationForm.calcVO.calcString = proxy.calcString; break; case ApplicationFacade.APP_PLUS_CLICK:　　　　　　　　　　　　　　　　 proxy.plusNumber(); break; case ApplicationFacade.APP_MINUS_CLICK:　　　　　　　　　　　　　　　 proxy.minusNumber(); break; case ApplicationFacade.APP_CLEAR_CLICK:　　　　　　　　　　　　　　　 proxy.clear(); // 画面に表示している情報の書き換え calclationForm.calcVO.calcString = proxy.calcString; break; case ApplicationFacade.APP_EQUAL_CLICK:　　　　　　　　　　　　　　　 proxy.calcEqual(); // 画面に表示している情報の書き換え calclationForm.calcVO.calcString = proxy.calcString; break; } } } } ① public class CalclationPanelMediator extends Mediator implements IMediator Mediatorクラスの宣言部。ここではMediatorクラスの継承とIMediatorインターフェースの実装を宣言しています。 Mediatorクラス（IMediatorインターフェース）にはhandleNotificationというメソッドを持っています。後述しますが、このメソッドをオーバーライドすることにより、ビジネスロジックとの橋渡しをします。またこのクラスがハンドルするイベントを登録するためのメソッドであるlistNotificationInterestsというメソッドもあります。これもオーバーライドすることにより、このMediatorクラスがハンドルできるイベントを登録するわけです。 ② private var proxy:CalclationProxy; ビジネスロジックであるProxyクラスのインスタンスを保持するための変数です。このMediatorクラスの中で共通的にProxyクラスを使用したいためにインスタンス変数としています。 ③ public static const NAME:String = "CalclationPanelMediator"; Facadeクラスに登録するための名前をここで定義しています。ここで定義された名称でFaçadeクラスの中にインスタンスが生成されます。よって、この名前はアプリケーションの中でユニークになっている必要があります。 ④ public function CalclationPanelMediator(view:Object):void コンストラクタです。引数としてview:Objectを受け取るようになっていますが、このViewの実態はViewコンポーネントそのものです。今回の計算機サンプルでは上記MXMLの解説でお話した「CalclationPanel.mxml」のインスタンスが対象のViewコンポーネントになります。 ⑤ super(view); 親クラスのコンストラクタを呼び出しています。ここでは上記④のコンストラクタで指定されたViewコンポーネントを引数として渡しています。これを実行することで親であるMediatorクラスのインスタンス変数「viewComponent」に設定しています。このview（さらにいえばCalclationPanel.mxmlのインスタンス）が設定されます。以降、このクラスの中ではviewComponentというインスタンス変数で Viewコンポーネントを扱っていきます。が、直接的に扱うのではなくGetterメソッドを用いて利用しています（後述⑧）。 ⑥ calclationForm.addEventListener(CalclationPanel.click0,onClick); イベントを登録しています。ここでいうcalclationFormというのは後述⑧で示している通り、実態はviewComponentというインスタンス変数です。これは上記⑤でも出てきましたね。そうです。CalclationPanel.mxmlのインスタンスをさしています。ここでこのCalclationPanel.mxmlが送出するイベントのリスナとハンドラを登録しているわけです。ここまで来てようやくCalclationPanel.mxmlで設定していた送出イベントの名前定義を利用できるわけです。しかし、MXMLが送出するイベント名を使って、リスナとハンドラを登録しているわけですから、 Cairngormのように「（FrontControllerに）イベントがいっぱいでよくわからない」ということはないと思います。このMediatorクラスでイベントを登録しているわけですから。 ⑦ proxy = facade.retrieveProxy( CalclationProxy.NAME ) as CalclationProxy; ここではこの中で利用するProxyクラスを取得しています。 Proxyクラスはビジネスロジックを実装しているクラスであることは前に述べました。このProxyクラスのインスタンスを取得することにより、 Mediatorクラスの中で自由に利用できるようになります。 ⑧ public function get calclationForm():CalclationPanel Getterメソッドです。後述の⑨を返却しています。 ⑨ return viewComponent as CalclationPanel Mediatorクラスのインスタンス変数であるviewComponentのインスタンスをCalclationPanelのインスタンスにキャストして返却しています。 viewComponentというインスタンスをそのまま扱わないのは、viewComponentというのはオブジェクトであり、 CalclationPanelというキャストをしてあげなければ、機能として何もないのと同じだからです。この辺り、 var obj:Object = new Object(); とプログラムを書いてみて、この「obj」という変数のプロパティやイベント、メソッドを見てみるとよくわかると思います。（EclipseやFlexBuilderではヘルプがでますので。そうでない方はFlexAPIドキュメントのObjectクラスをご覧ください。） ⑩ private function onClick(e:Event):void 上記⑥で登録していたハンドラです。 CalclationPanel.mxmlで起こったイベントを受け取るハンドラですね。 ⑪ var calc:CalclationVO = calclationForm.calcVO ここではValueObjectであるCalclationVOを取得しています。 ValueObjectクラスは画面に値を表示する際の器として使用しています。 ⑫ switch( e.type ) 　　イベントタイプの判定です。 ⑬ case CalclationPanel.click0: ⑫で判定するケース文ですね。ここではイベントタイプがclick0であったら、このCase文の中身を実行するようになっています。 Case文は多々ありますが、やっていることは基本的に同じなので、説明は省略しています。 ⑭ proxy.setNumber("0"); 　　ビジネスロジックを持つproxyのsetNumberというメソッドを呼び出して、　　proxyに入力された（ここではクリックされた）番号を通知しています。　　ここで入力された値を設定しないと、設定する機会がないので、　　このタイミングで設定しています。　　このときの「ボタンを押した」というイベントはこの中でしか取れないからです。 ⑮ sendNotification(ApplicationFacade.APP_NUMBER_CLICK, calc); イベント登録用クラスであるNotificationをイベントとして送出しているメソッドです。ここで送出されたNotificationイベントは後述⑰で登録されたイベントに対応しており、これを⑱のメソッドhandleNotificationでハンドルします。ここでNotificationを起こすことにより、ビジネスロジックとの完全分離を目指しているわけです。今回の計算機ではビジネスロジックはたいしたことをやっていませんのであまり必要性は感じないかと思われますが。 ⑯ override public function listNotificationInterests():Array MediatorクラスのメソッドlistNotificationInterestsをオーバーライドしています。このメソッドでこのMediatorクラスが起こすNotificationイベントを登録します。登録の仕方は後述の⑰の通りです。このメソッドは親のコンストラクタの中で自動的に呼ばれます。このメソッドが定義されていないと、 ⑮で呼び出しているメソッド「sendNotification」は意味がないので、きちんと定義しましょう。 ⑰ return [ApplicationFacade.APP_NUMBER_CLICK, ApplicationFacade.APP_PLUS_CLICK, ApplicationFacade.APP_MINUS_CLICK, ApplicationFacade.APP_CLEAR_CLICK, ApplicationFacade.APP_EQUAL_CLICK] このMediatorクラスが起こすNotificationイベントをArray型として返却しています。 ⑱ override public function handleNotification(notification:INotification):void ⑮で送出させたNotificationイベントのハンドラです。　　⑯、⑰で設定したイベントのハンドラがこのメソッドになります。　　この中でビジネスロジックを実装しています。　　というよりはProxyクラスの呼び出しをコントロールしているといったほうが正しいでしょう。　　今回は計算機なのでたいしたことはやっていませんが、　　Proxyクラスのメソッドを使っての計算やValueObjectへの値の設定はここでやっていることがお分かりいただけると思います。 ⑲ switch ( notification.getName() ) 送出されたNotificationの名前の判定です。 ⑮で送出されたものの名前を判定しています。 ⑳ case ApplicationFacade.APP_NUMBER_CLICK ⑮で送出された名前のCase文ですね。このCase文の中でProxyクラスの呼び出しやValueObjectへの値の設定などを行っています。ビジネスロジックというよりはProxyのコントロールとValueObjectの設定を主にやるところですね。実際のビジネスロジックはProxyというクラスがいるわけですから、ここではそのコントロールと画面に表示する部分のValueObjectの制御だけを行えばいいのです。ここでサンプルの解説を終わります。ここまで来て、結局、どうやって流れるの？っていう素朴な疑問について、曖昧なままよくわかりませんので、図化してみました。 PureMVCの初回起動時は動きは以下の図の通りです。サンプルで利用した計算機アプリを元にしていますので、Commandなどの動きにはほかにバリエーションがあるかもしれませんので、とりあえずはこんな動きなんだということでお願いします。 #image(http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=PureMVC_Map.JPG,width=500,height=300,title=PureMVC_Map) [[元の大きな画像はこちらから>>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=PureMVC_Map.JPG]] PureMVCのイベント駆動時の動きは以下の図の通りです。こちらもサンプルの計算機を元におしていますので、あしからず。いかがでしたでしょうか？ここまでお送りしましたPureMVCについてをサンプルを交えて解説してきましたが、全体の俯瞰図は以下の通りです。 #image(http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=PureMVCFrowChart.JPG,width=500,height=300,title=PureMVCFlow) [[元の大きな画像はこちらから>>http://www39.atwiki.jp/flex_framework/?cmd=upload&act=open&page=PureMVC&file=PureMVCFrowChart.JPG]] かなり大きいです、ごめんなさい。大体の概念はMVCと変わりないことがお分かりいただけたかと思います。ただFlexはイベント駆動型のアプリケーションなので、どうしてもイベント中心になりがちですが、その辺りを解決してくれるのがPureMVCではないでしょうか。まだまだいろいろFrameworkはあると思いますので、折を見て触れていきたいと思います。とりあえず、今回はここまでです。お付き合いいただきありがとうございました。