Cairngorm_Framework


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

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

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

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

メリット

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

デメリット

  1. 画面数が増えるとイベントを管理するControllerが煩雑になり、可読性を損なう。
  2. Event、Commandがすべて1対1になるので、イベントの数の2倍のクラス(EventクラスとCommandクラス)ができてしまう。

なまえ:
コメント:
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。