5

ビュー内の複雑なコンポーネント間の相互作用を調整するためのベスト プラクティスは何ですか?

コンボ ボックスやグリッド コントロールのような単純なウィジェットについて話しているのではなく、複数のウィジェットで構成されていて、それ自体で単体テストを行うに値するコンポーネントについて話しているのです。

あなたは:

  1. 各コンポーネントの抽象インターフェースを定義し、コントローラーに任せる依存性注入を介してそれらを接続し、メソッド呼び出しを介して互いに直接通信できるようにしますか? したがって、コンポーネントは他のコンポーネントのインターフェースを認識します。
  2. 各コンポーネントが起動できるイベントを定義し、コントローラーに任せるイベントリスナーを介して相互に直接接続しますか? したがって、コンポーネントには、他のコンポーネントのイベント シンクにアタッチされたイベント ハンドラがあります。
  3. 各コンポーネントの抽象インターフェイスを定義し、それらが起動できるイベントを定義し、コントローラーに任せるすべてのイベントをリッスンし、インターフェイスでメソッド呼び出しを実行しますか? したがって、コンポーネントは他のコンポーネントに対して完全に不可知です。
  4. オブザーバー パターンの古典的なアプリケーションですか?
  5. 他に何か?

更新: #1 から 3 までの「let the Controller ...」を削除しました。これらの場合、ルーティング/オーケストレーションを行う必要があるのは必ずしも Controller であるとは限らないためです。ビュー自体である可能性があります。

最近のプロジェクトで方法 3 を採用しましたが、コンポーネントのデカップリングと個々のテスト容易性に満足しています。しかし、コンポーネントの配線を合理化できた気がします。私の場合、メインの View オブジェクトは、各コンポーネントに複数のイベント リスナーを追加し、適切なコンポーネントのメソッドを呼び出す必要があります。これは、時々ローカル処理 (モデルとの対話など) を行った後に行います。イベント ハンドラーを追加するためのコードは少し乱雑に見えます。特に、それを行うクリーンな方法を探しています。

4

2 に答える 2

4

オプション #3 は Mediator パターンのように聞こえますが、多くの場合、更新ロジックとオブジェクト間の通信が複雑な場合に最適な方法です。また、制御ロジックと初期化を一元化するという追加の利点もあります。これにより、これらのタイプのケースのトレースとデバッグが容易になります。

于 2008-10-10T13:58:43.080 に答える
0

あなたはこの質問について自分の質問に答える知識を持っているように思えますが、飛び込む自信がないだけかもしれません。

追加できることの 1 つは、すべてのオブジェクトの間にコンポーネント マネージャーを配置して、通信を容易にすることです。過去に同様のことを行ったとき、管理オブジェクトは各コンポーネントからデータを取得し、データをマージして、1 つの大きな要求としてモデルに渡すだけでした。各コンポーネントには、呼び出してデータを渡すデリゲートがあり、もちろん、そのデリゲートの実装はコンポーネント マネージャーにありました。

また、そのマネージャー オブジェクトをネットワークへのプロキシとして機能させ、複雑さが増すのを待ってから SRP に準拠し、その責任を独自のクラスにしました。

基本的に、あなたが言ったことはすべて良いように聞こえます。飛び込んで探索することをお勧めします。

于 2008-10-10T05:37:01.233 に答える