4

我有一个表示小部件的视图类和一个随附的演示者类。我还有一个用于拥有小部件的窗口的视图类，以及一个用于窗口视图的伴随演示者。窗口操作小部件，所以我需要窗口展示器与小部件展示器进行通信。可视化：

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

我不确定的是如何构造对象。我知道 MVP 架构并没有处理这个问题，而是“把它留给读者练习”。我尝试过的事情：

  1. 视图构造了它们的演示者，并window_view构造了widget_view. 但是，window_view在它的构造函数中需要额外的参数，它不应该关心的参数，只是为了实例化演示者。我也不确定如何window_presenter访问widget_presenter. 为for添加一个widget_presentersetter 来填充对我来说感觉不对。window_presenterwindow_view
  2. 消除两个演示者之间的通信线路。通过window_presenter交谈。这对我来说似乎也不理想，因为它需要添加代码来仅用于和之间的通信。它也只允许一种方式的通信，并且它还增加了允许外部与它的演示者通信的脂肪。widget_presenterwindow_viewwindow_viewwindow_presenterwidget_presenterwidget_view

我可以想象这里的复杂性呈指数增长，因为window_presenter需要与其他演示者交谈，或者其他演示者需要与其他演示者交谈。

我还想过在这里添加一个中介对象来吸收所有这些相互通信和依赖关系，但是在这一点上，将逻辑与表示分离的整个想法开始感觉非常昂贵和非常复杂。我肯定在这里做错了什么。

4

1 回答 1

0

我发现这篇文章可能会有所帮助：

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

特别是，您似乎在谈论“经典” mvc，其中每个小部件都是具有自己控制器的视图。我认为这篇文章谈论的是世界的“表单”视图，每个“表单”都是视图的集合，并且只有一个控制器或演示者。我认为 MVP 属于“表单”视图，因此通常每个表单一个演示者。

于 2012-10-04T02:27:19.773 回答