mvp - 模型/ View /演示者 : presenter-to-presenter communication

Question

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

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

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

View 构建了它们的演示者，以及 window_view构造 widget_view .但是，window_view在它的构造函数中需要额外的参数，它不应该关心的参数，只是为了实例化演示者。我也不确定window_presenter如何将访问 widget_presenter .添加 widget_presenter设置为 window_presenter为 window_view填写对我来说不合适。

消除两个演示者之间的通信线路。 window_presenter与 widget_presenter 交谈通过 window_view .这对我来说似乎也不理想，因为它需要向 window_view 添加代码仅用于window_presenter之间的通信和 widget_presenter .它也只允许一种方式的通信，而且它还给widget_view增加了脂肪。允许外部人员与其演示者进行交流。

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

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

Answer 1

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

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

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