2

私が学んだすべての GWT / MVP の例は単純すぎて、少し複雑なモデル オブジェクトの表示と処理に関するベスト プラクティスを明確に示すことができません。

たとえば、ほとんどの例は、クリック ハンドラーをビューのいくつかの TextBoxes にアタッチするプレゼンターのようなものです...保存がクリックされると、プレゼンターの save() が呼び出され、更新された値を取得するだけで済みます。 MVP スタイル。しかし、それはそれほど現実的ではありません。

たとえば、次のようにします。

PresenterX - 「モデル」オブジェクトを取得します。さまざまなプリミティブの数が不明なオブジェクトなどを考えてみましょう

ViewX - モデル オブジェクトをテーブルに表示し、編集/再保存できるようにする必要があります。

...とても基本的なことのように聞こえます。しかし、表示する必要があるモデル オブジェクトのフィールドの量はわかりません。そのため、行/列の動的数に関連している可能性があります。おそらくテーブルには問題ありません...しかし、プレゼンターはこれをビューのテーブルにどのように与えるべきですか? ビューが理解するモデルオブジェクトとして、またはビューが本質的に理解する必要がある一連のリストに分割します。

また、特定のフィールドが編集可能である可能性がありますが、モデル オブジェクトを取得するまでそのフィールドは不明です (たとえば、モデル内の何かが編集可能なフィールドを決定します)。おそらくプレゼンターですが、MVP の方法でビューに反映するにはどうすればよいでしょうか?

最後に、ビューに「保存」ボタンがあるとしましょう...変更されたテーブル内のすべての行を把握するのは誰の仕事ですか?

ビューがモデルをもっと理解する必要があるか、プレゼンターがビューをもっと理解する必要があるように思えます-どちらも素晴らしいMVPではありません:( ...または、おそらくいくつかの中間オブジェクトが必要です。

この種のもの (Editors/RequestFactory など) には、より優れた/新しい便利な方法があることは知っていますが、上記のシナリオに関する提案を探しています。

4

1 に答える 1

1

私が理解しているように、MVPはMPVポイントを持つラインです。したがって、P は両方と相互作用しますが、M と V は P とのみ相互作用します。

また、MVP の設計目標の 1 つは、テスト可能な P と M を持つことです。つまり、V はモック バージョンに置き換え可能でなければなりません。そのため、V は実装に依存するインターフェイスを (たとえばHasClickHandlersの代わりにButton) 公開すべきではありません。

addColumn(..)ここで、V が汎用テーブルを表示する必要がある場合は、列を定義addRow(..)してデータを追加するための汎用メソッドを作成する必要があります。新しいCellTableものは非常に柔軟で、動的に列を追加することをサポートしています。

変更について - V は通知し、P は行動する必要があります。また、Editors私見が MVP にうまく適合しない新しい もありますが、使いやすいはずです。

于 2011-03-04T13:02:58.827 に答える