2012-03-20 23 views
1

GWTP(GWT 2.4)を使用して新しいアプリケーションを開発しています。GWTPのモデル変更イベントの変更

各コンポーネントの責任、それらの間のコミュニケーションは重要ですが、モデルコンポーネントには焦点があまりありません。

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

モデルが変更されたイベントをどのように伝達するのだろうか。 私はそれを見ると、2つの方法があります。

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

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

通常、両方のアプローチが必要ですが、最初のアプローチをサポートしている例は見つけられません。通常、最初のアプローチが考慮されているときはMVCよりもMVC設計です。

あなたはどう思いますか? 推奨事項はありますか?

最初のケースでは、ベン

答えて

0

、あなたが登録されたリスナーのいくつかの種類にPropertyChangeEventを使用することができるはずあなたがテキストフィールドを持っていた場合、一般的に、そのフィールドのプロパティ変更リスナーがあるだろうし、その後、フィールドが変わるたびに、いくつかのイベントがバスに発射されます。もちろん、あなたは依然としてUIからオブジェクトをモデル化する必要があります(私はGwittirを提案します、これはすべて非常にうまくいきます)。

2番目の問題は似ています。サーバーは、あなたが持っている手段を使ってコールバックを行い、その後、「新しい値を持つフィールドは何か」というイベントをトリガする必要があります。個々のフィールド(登録して聞くべきである)が、そのイベントを聞き、適切に反応するかどうかを決定することができる。

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

私はこの設定が意味のある方法でMVPに違反しているとは思わないが、あなたのプレゼンターがバスを聴いてビューを変更するように指示することができる純粋なMVPになると思うが、無意味な抽象、結合、バグの原因などの層のようなもので、後でもっとうまく動作します。

私はそれが間違った質問に対する答えであるかどうかを教えてください。私が問題の微妙なことを理解していなければ私は編集します。