31

MVPでビューはどのように作成されますか？プレゼンターは常にそれらを作成しますか（サブビューの場合はビューに加えて）？それとも、別のサードパーティコンポーネントまたはアプリ、あるいはそれらを作成するものですか？

また、おそらくDojo Toolkit / ExtJS（つまりJavaScript）でこれを実行することを追加しましょう。

だから、私はこれらのコード行を持っています：

var v = new MyApp.view.User();
var p = new MyApp.presenter.User();

両方の行を正確にどこに配置する必要がありますか？プレゼンターはビューをインスタンス化しますか、またはその逆ですか？そして、何が最初のインスタンスをインスタンス化しますか？

4

5 に答える 5

49

場合によります ...

MVPの主な目標は、複雑な決定ロジックをUIコードから分離して、理解と保守の両方が容易になるようにすることです。多くの場合、別の目標は、プレゼンターの決定ロジックをテスト可能にすることです。

MVPパターンは2004年にファウラーによって記述され、彼はパターンを監督コントローラー（SC）とパッシブビュー（PV）に分割することにより、2006年に引退しました。SCでは、ビューはモデルにバインドされますが、PVではバインドされません。PVでは、ビューはプレゼンターによって直接変更されるだけです。

SCとPVの両方で、プレゼンターはビューを更新し、テキストの入力やボタンの押下など、ユーザーがビューに加えた変更に対応する必要があります。ビューにプレゼンターのメソッドを呼び出させると、ビューがプレゼンターへの参照を必要とするため、説明する問題が発生します。その逆も同様です。これを行うと、誰がそれをすべて開始するかを簡単に決定できます。オプションは次のとおりです。

  1. ビューはプレゼンターのインスタンスを作成します。ビューがロードされると、プレゼンターの初期化関数でビューがプレゼンターに渡されます。
  2. 逆の方法：Presenterはビューを作成し、ビューの初期化関数でビューに渡します。
  3. ViewとPresenterの両方を作成し、それらを相互に接続し、両方を初期化する3番目のオブジェクトを導入します。

すべてのオプションにより、関心の分離と意思決定ロジックのテスト容易性の向上という「MVP目標」を達成できます。これらの方法は理論的には正しいか間違っているとは思いません。使用するテクノロジーに最も適した方法を選択するだけです。また、アプリケーション全体で一貫性を保つことが最善です。

于 2011-06-21T19:57:50.760 に答える
6

これらはあなたのオプションです：

var cvp = new ContactViewPresenter(new ContactView());

ContactViewPresenterコンストラクターは、を設定しthis.view = viewParam、を設定しますthis.view.presenter = this。プレゼンターにコードを保持し、必要に応じてビューを交換し、テストのためにビューのモックを渡すことができます。

var cv = new ContactView(new ContactViewPresenter());

ContactViewコンストラクターセット、、this.presenter = cvpParamおよびthis.presenter.view = this。ビューにはいくつかのロジックがありますが、多くはありません。必要に応じてプレゼンターを交換できます。

ContactView cv = new ContactView();
ContactViewPresenter cvp = new ContactViewPresenter();
cv.presenter = cvp;
cvp.view = cv;
cv.init();
cvp.init();

これはもっとたくさんのコードです。

ContactViewPresenter cvp = new ContactViewPresenter();

コンストラクターはセットthis.view = new ContactView()とを作成しますthis.view.presenter = this。

ContactView cv = new ContactView();

コンストラクターセットthis.presenter = new ContactViewPresenter()とthis.presenter.view = this

最後の2つは少し結合しすぎているようです。

1つは、コードがPresenterにとどまり、テストが容易になるという点で優れています。

2つは、プレゼンターをあまり気にする必要がなく、ビューについてもっと心配できるという点で優れています。

于 2012-05-20T19:09:37.220 に答える
2

プレゼンターがビューをインスタンス化する必要はないと思います。これは、MVPトライアド外のエンティティ（データ指向の意味ではなく、一般的なエンティティを意味します）によって実行される必要があります。たとえば、制御の反転（IoC）フレームワーク（IoCについて聞いたことがない場合は、Martin Fowlerの記事を確認してください）や、ユーザー構成を担当するアプリケーションモジュールなどです。

于 2011-06-19T22:19:39.883 に答える
0

WebFormsを使用している場合は、WebForm OnLoadまたはInitをプレゼンターを作成する場所にする必要があります。これにより、WebFormが実装するビューへのインターフェイス参照が渡されます。

だから、このようなもの：

Presenter _presenter;

OnLoad(object sender, EventArgs e) 
{
  _presenter = new Presenter(this);
  _presenter.Initialise();
}

そして、Presenterコンストラクターは次のように定義されます。

public class Presenter
{
  public Presenter(IView viewReference)
  {
    _viewReference = viewReference;
  }
}
于 2011-06-06T08:19:08.353 に答える
0

用語が少し間違っているかもしれませんが、相互作用の構成ルートを特定する必要があると思います。相互作用を開始するものは何ですか？

私が示したWebformsの例では、WebformはHttpパイプラインによって作成され、OnInitまたはOnLoadイベントは、プロセスに「フックイン」できるパイプラインの最初のポイントです（必要なコンテキストに応じて）。したがって、プレゼンターを作成し、それにWebフォームの具体的なインスタンスをビューインターフェイスとして提供します。

あなたが議論しているJavascriptフレームワークはわかりませんが、初期化/呼び出しのステップがあると思います-ASP.NET MVCでは、これはActionInvokerが関与するときであり、コンソールアプリのメインです。

于 2011-06-21T15:37:15.787 に答える