Cairngorm_Framework

＜Cairngormの批評と図式＞
１．Cairngormの批評

項目名	Cairngorm	批評
理解しやすさ	◎	イベントを一元管理化しているので、イベントと実行されるロジックが理解しやすいです
導入しやすさ	○	オープンソースというところから、英語版ではありますがサンプルもあるので、比較的導入が簡単です。
コーディング量	×	１イベントにつき、１実行ロジックというプログラムになってしまいますので、コーディングの量はどうしても増えてしまいます。
用意されているクラス郡の使いやすさ	○	下記フローチャートをご覧いただきますとわかりますが、基本的なクラスは多くありません。また役割もはっきりしているので使いやすいと思います。
テスタビリティ	×	これといったテストの方法がなく、「目視による動作確認テスト」くらいしか有効なテスト手段がありません。
用意されているドキュメントの量	◎	オープンソースということでサンプルは比較的多いです。ほとんどが英語ですが、サンプルもあるので、わかりやすいと思います。
サーバー技術との親和性	◎	サーバーとFlexのロジックを分離する、というのもこのフレームワークの目的ですので、サーバサイドの技術を選びません。
改造のしやすさ	×	１イベントにつき、１実行ロジックということは既に述べましたが、その都合上、どうしても１イベント、複数実行ロジックという改造が難しい点があります（できないわけではありません）。
保守のしやすさ	○	１イベント、１実行ロジックですので、イベントを見れば実効されているロジックがわかりますので、あちこち見る必要がなく、見やすいプログラムになります。
知名度	○	Adobe社がオープンソースとしているので、知名度は高いかと。
導入しやすい案件規模	画面数が～３０くらいまで	１イベント、１実行ロジックという形式をとりますので、画面数が多くなればそれだけイベント、ロジックの数が増えてきます。画面数が増えればイベントが増えるとうことで、イベントが一元管理される、ということはそれだけ管理するイベントが膨大になりますので、それだけで大変になります。
教育コースが存在するか	×	今のところ私は教育コースは知りません。独自で解釈しています。

 
２．Cairngormのフローチャート図

元の大きな画像はこちら

「フローチャート解説」
View層ではCairngormEventというものを発生させて、それをController層に通知するようになっています。
そのEventを受け取ったControllerは１イベント、１実行ロジックという風にマッピングされている実行ロジック（Cairngormの中では
Commandと表現しています）を呼び出して、そのコマンドの中で業務ロジックを記述し、データバインドをしているDataModelへ
データを渡すようにしています。
 
実際にサンプルを動かしてもらったほうが早いでしょう。
※サンプルはAdobeAIRで作られています。FlexBuilder3のプロジェクトをアーカイブしたものをサンプルとしておきます。
 
サンプルはこちらから

 
実行していただけるとよりわかりやすいと思います。
 
サンプルの解説はこちらから

メリット

1. イベントが一元管理されどのイベントがどのロジックを呼んでいるかすぐにわかる。
2. サーバサイドとのやりとりが窓口がＤｅｌｅｇａｔｅになることにより、サーバサイドからの返却がわかりやすい。

デメリット

1. 画面数が増えるとイベントを管理するＣｏｎｔｒｏｌｌｅｒが煩雑になり、可読性を損なう。
2. Ｅｖｅｎｔ、Ｃｏｍｍａｎｄがすべて１対１になるので、イベントの数の２倍のクラス（ＥｖｅｎｔクラスとＣｏｍｍａｎｄクラス）ができてしまう。