1

私はMVPパターンが採用されているアプリケーションに取り組んでいます。それはまだ開発の初期段階なので、私はまださまざまなデザインの選択について批判的に反省する贅沢を持っています。

モデルは、いくつかの構造体とそれらを操作するいくつかのAPI関数で構成されています。わかりやすくするために、これがモデルであるとしましょう。

struct ComplexNumber {
    double real;
    double imag;
};

Complex_Add(ComplexNumber x, ComplexNumber y);
Complex_Mul(ComplexNumber x, ComplexNumber y);

次に、ビューが表示されます。ここではプリミティブ型のみを使用しています。

class IComplexView {
public:

    virtual double GetReal1() = 0;
    virtual double GetImag1() = 0;

    virtual double GetReal2() = 0;
    virtual double GetImag2() = 0;
    // Setters snipped
};

プレゼンターでは、私が理解できる限り、ビューからモデルへ、およびモデルからビューへのデータ変換のためのいくつかの方法があります。私は通常、ReadView（）メソッドとUpdateView（）メソッドを持っています。プレゼンターのその部分はこれに非常に近いものに見えるでしょう：

class ComplexPresenter {
    ICopmlexView view;
    ComplexNumber x;
    ComplexNumber y;

    // ...

    static void ReadView() {
        x.real = view.GetReal1();
        x.imag = view.GetImag1();

        y.real = view.GetReal2();
        y.imag = view.GetImag2();
    }
}

UpdateView()ビューがモデルから入力されるように、逆になります。

その設定では、問題は次のとおり です。ビューからモデル内の変数/プロパティを上記の単純なもの以外にバインドする「賢い」方法はありますか？

これで私が目にする問題は、データを移動するためだけに追加されるコードが比較的大量にあることです。最初にIViewにアクセサーがあり、次にReadView（）メソッドとUpdateView（）メソッドがあります。スクリプトをビルドイベントに接続して、このすべてのコードを自動生成できると思いますが、気付かない他の選択肢があることを期待していました。

もう1つのアプローチは、MVPを完全に削除するか、具体的にはプレゼンターを削除し、UI<->ロジックを分離するだけです。明らかな欠点は、結合が強いことですが、一方で、コードの量が著しく少なくなる可能性があります。

4

1 に答える 1

2

あなたが説明したMVPバリアントは、次のように参照される場合がありますPassive View-ここでMartinFowlerのエントリを参照してください。その欠点は確かに、モデルとビューを同期するためのボイラープレートコードがたくさんあることです。data binding何らかのメカニズムを 使用する代替手段は、Supervising ControllerまたはPresentation Model（別名View Model）です。

プレゼンターをドロップし、UI<->ロジックの分離を行うだけです。

ここでの1つの危険は、バインディングメカニズムが複雑なケースを処理できない可能性があることです。

一般に、次の2つの解決策を検討してください。

  • Presentation Modelビューからプレゼンテーションモデルへのバインディングとプレゼンテーションモデルからドメインモデルへのバインディングの2層のバインディングを使用できます。低い結合を維持しますが、これら2つのメカニズムを実装すること自体が面倒な場合があります。

  • Supervising Controllerビューからドメインモデルへのバインディングを使用し、それ自体はバインディングメカニズムでは処理できない複雑なケースのみを処理するため、両方の長所を活用できます。

于 2013-03-20T12:54:58.583 に答える