Cairngormベースのアプリケーションのレイヤーの複雑さを軽減

Question

SWFAddressのようなツールをいくつかの巧妙な方法で使用して、既存のクライアントサーバーアーキテクチャを緩和できますか。 RESTのようなパターンマッピングなどを導入する可能性さえあると思います。

私が現在行っているのは、すべてのケアンゴームギドリンをフォローすることです。これにより、すべてが理にかなっている一連のコマンドがすでに作成されていますが、ビジネスデリゲートなどを含めて、拡張とリファクタリングに苦労しています。アプリケーション（そして実際にはレイヤーが役立つはずでした、タイト...多分私はそれを完全に正しく行っていません、私は認めます）。

とにかく、私が考えたのは、飛び回るアプリケーションイベントの数と、それらに応答するコマンドの数をなんとかして減らすことでした。実際、レイヤーの複雑さを理解できれば、ビューをロジックと結合してもまったく問題ありません。

つまり、ボタンのクリックをURLパターンにバインドする（またはSWFaddressを使用してURLをグローバルに変更する）ことができます。一方、URLの変更を待って再フォーマットし、必要なマッピングを念頭に置いたサービスデリゲートに渡すので、呼び出すメソッドを知っているか、URLを直接渡すこともできます。 HTTPSErviceに。次に、デリゲートはサーバーの応答を処理し、モデルを更新します。これにより、バインディングを介してビューが更新されます。

コマンドを完全に捨てるつもりはありません。 （クライアント自体の内部での）内部対話のスケジューリングには適していると思いますが、サーバーとの通信にそれらを使用することは控えたいと思います。

私は正しい道を進んでいますか？

Answer 1

Cairngorm以外のフレームワークに切り替えることに反対していますか？あなたは、ほとんどの人の不満がそれについて何であるかを完全に説明しました。それは主にFlex開発の昔から存在していると思います...

私が知っている開発者のほとんどは、より「最新の」フレームワークを使用しており、通常は依存性注入（DI）に重点を置いています。

これは、今日使用されているさまざまなframeowkrsを分析するための良い出発点です。

http://www.adobe.com/devnet/flex/articles/ flex_framework.html

さらに読むために...

私は個人的にSwizを好み、すべてのプロジェクトで使用しています。それでもコマンドパターンに焦点を当てていますが、説明したように、レイヤーの複雑さの多くを軽減します。

あなたの質問が、どうすればケアンゴームをもっと似ていないようにすることができるかということだったとしたら...まあケアンゴーム...それなら私はそこであなたを助けることができないのではないかと思います。 :)

乾杯と幸運を！