4

ウィジェットを表すビュー クラスと、付随するプレゼンター クラスがあります。また、ウィジェットを所有するウィンドウ用のビュー クラスと、ウィンドウ ビュー用の付随するプレゼンターもあります。ウィンドウはウィジェットを操作するので、ウィジェット プレゼンターと通信するにはウィンドウ プレゼンターが必要です。視覚化するには:

+-------------+        +------------------+
| widget_view |<------>| widget_presenter |
+-------------+        +------------------+
       ^                         ^
       |                         |
       |                         V
+-------------+        +------------------+
| window_view |<------>| window_presenter |
+-------------+        +------------------+

私がよくわからないのは、オブジェクトを構築する方法です。MVP アーキテクチャがこの問題に対処していないことは知っていますが、「読者の演習として残しています」。私が試したこと：

  1. ビューはプレゼンターを構築し、 をwindow_view構築しwidget_viewます。ただし、window_viewコンストラクターに追加のパラメーターが必要です。これは、プレゼンターをインスタンス化するためだけに、気にする必要のないパラメーターです。window_presenterまた、が にアクセスする方法もわかりませんwidget_presenter。forにwidget_presenterセッターを追加して記入するのは、私には適切ではありません。window_presenterwindow_view
  2. 2 人のプレゼンター間の通信回線を取り除きます。を通じてwindow_presenterと話します。との間の通信のためだけに にコードを追加する必要があるため、これも理想的ではないように思えます。また、一方通行の通信のみを許可し、部外者がプレゼンターと通信できるように脂肪を追加します。widget_presenterwindow_viewwindow_viewwindow_presenterwidget_presenterwidget_view

window_presenterここでは、他のプレゼンターと話す必要があるか、他のプレゼンターがさらに他のプレゼンターと話す必要があるため、複雑さが指数関数的に増大することを想像できます。

ここにメディエーター オブジェクトを追加して、これらすべての相互通信と依存関係を吸収することも考えましたが、この時点で、ロジックをプレゼンテーションから分離するという全体的なアイデアは、非常にコストがかかり、非常に複雑に感じ始めます。確かに私はここで何か間違ったことをしています。

4

1 に答える 1

0

I found this article that might help:

http://martinfowler.com/eaaDev/uiArchs.html

In particular, it looks like you are talking about the "classical" mvc, where each widget is a view with its own controller. I think the article talks about a "forms" view of the world, were each "form" is a collection of views, and there is only one controller or presenter. I think MVP falls under the "forms" view, so typically one presenter per form.

于 2012-10-04T02:27:19.773 に答える