1

GWTP (GWT 2.4) を使用して新しいアプリケーションを開発しています。

プレゼンター ビューの設計方法 (各コンポーネントの責任、それらの間の通信) に関する記事は非常に多くありますが、モデル コンポーネントにはあまり焦点が当てられていません。

私たちのアプリケーションでは、GWTP のアクションを使用し、サーバーから DTO を受け取ります。これに対して主に CRUD を実行します。各 DTO の UI-Entity ラッパーがあります。この UI エンティティは、それを表示するために必要なすべてのメタデータ (プロパティ、表示名など) を保持し、すべてのプロパティの設定/取得を提供します。

機種変更イベントの伝播方法が気になる。私が見る限り、2つの方法があります：

  1. UI エンティティはイベントを発生させます。
  2. アクションは、サーバーからのコールバックでイベントを発生させます。

2つの方法の大きな違いは、最初のオプションがモデルを「ライブ」にすることだと思います-ユーザーが変更を行っている場合、サーバーに送信されなくてもアプリケーションに反映されます。2 番目のオプションでは、データがサーバーで実際に変更された場合にのみ、アプリケーションはデータ変更イベントを認識します。

私が見ているように、通常は両方のアプローチが必要ですが、最初のアプローチをサポートする例を見つけることができません.

どう思いますか？推奨事項はありますか？

ベン

4

1 に答える 1

0

最初のケースでは、登録されたある種のリスナーで propertychangeevent を使用できるはずです。一般に、テキストフィールドがある場合、そのフィールドにプロパティ変更リスナーがあり、フィールドが変更されるたびに、いくつかのイベントが取得されますバスに発砲。当然、UI からモデル オブジェクトにバインドする必要があります (Gwittir をお勧めします。これはすべて非常にうまく機能します)。

2 番目の問題も同様です。サーバーは、任意の手段でコールバックを作成し、バス上で「新しい値を持つフィールドは何でも!!!」というイベントをトリガーする必要があり、その時点で個々のフィールド(登録してリッスンする必要があります) は、そのイベントをリッスンして適切に反応するかどうかを決定できます。

したがって、基本的に、フィールドはバスをリッスンする必要があり、モデルがサーバー側または UI 側から変更されるたびに、バスにメッセージが送信され、関心のあるリスナーがその変更を処理できるようにする必要があります。これにより、設計が分離され、両方のケースが処理され、複雑なウィジェット レベルの操作が簡素化されます。

このセットアップが意味のある方法で MVP に違反しているとは思いません。最も純粋であるために (MVP をフレーム化するため)、プレゼンターにバスを聞いてもらい、ビューに変更を指示することができますが、私にはそれは無意味なレイヤーのように思えます抽象化、結合、およびバグのソースと、後でさらに多くの作業を行います。

それが間違った質問への回答である場合はお知らせください。問題の微妙な点を理解していない場合は編集します。

于 2012-07-05T12:33:16.430 に答える