2011-07-17 5 views
3

Robotlegs/PureMVCから来て、私はビューメディエーターの概念、つまり「ダミー」ビューからのイベント/要求をかなり聴き、さらなる要求をするコンポーネントにかなり精通しています。アプリケーション全体のシグナル/ eventを実行し、ビューからの要求に基づいてコマンドなどを実行します。Flex4 Host Componentはビューメディエーター/ヘルパーと同じ機能を持っていますか?

Flex 4で導入されたホストコンポーネントのアイディアをメディエータと同じに見なすことはできますか?私を少し気にする唯一のことは、SkinnableComponentやそれ以上継承するクラスを継承しているため、ホストコンポーネントもビューと見なされることです。私の見解では、メディエイターは完全にビューロジックから離れるべきです。

それにもかかわらず、私はスキン、ホストコンポーネント、およびそのホストコンポーネントのビューメディエーターを書くことは望ましくありません。これはかなりオーバーヘッドになり、抽象ではなくより複雑になるからです。

メディエータとしてホストコンポーネントを使用し、アプリケーションレベルのイベントディスパッチなどのアプリケーションレベルのロジックを配置する必要がありますか?

答えて

1

SkinnableComponentパターンでもこれで困っています。ビューのコンポーネントではないクラスで私の動作が好きです。私はコンポーネントを表示するための参照を持つことさえ好きではないので、私は "プレゼンテーションモデル"のパターンを好む傾向があります。 SkinnableComponentでは、ホストコンポーネントはビューコンポーネントですが、すべての共有ビヘイビアを保持します。それは少し混乱のように感じ、私はこれの巨大なファンではありません。しかし、再利用可能なskinnableコンポーネントを構築するには、かなり良い方法だと思います。たとえば、コンポーネント開発者の場合は素晴らしいことです。

私はそれがスキン、ホストコンポーネント、および分離された動作クラスを持つにはあまりにも複雑すぎると感じています。このため、私はskinnableコンポーネントのために彼らが私たちに与えたパターン(SkinとHost Component)に固執する傾向があります。それは私の経験ではテストをより複雑にしますが、それはそれです。

SkinnableComponent(私が一般的に外からの消費のためにスキン可能なコンポーネントを作成していないので)、私は単に分離されたプレゼンテーションパターン(通常はPM)を使い、スキニングパターンを無視します。

+0

+1私から;私はコンポーネント開発者にとってどれだけ「偉大な」ものなのか疑問に思っています。 Spark Architectureを拡張するには、MX Architectureを拡張する多くの課題があります。今は物事がさまざまなクラスの間で投げ込まれ、何が起こっているのかを理解することはこれまでより困難です。 – JeffryHouser

+0

@ www.Flextras.com:良い点。私はそれをSilverlightの「テンプレート化」と比較する観点から来ています。私はスキンクラスアプローチがより好きです。既存のスキンから派生して単一のプロパティを変更できるからです(テンプレート全体をコピーし、Silverlightのようにプロパティを変更するのではなく)。オブジェクト指向のアプローチは私がいいと思うものです。しかし、私は同意する、Flex4の "skinnableコンポーネント"パターンで、まだ多くの摩擦があります。 –

関連する問題