模型/视图/主持人：主持人对演示者通信

Question

我有一个表示插件的视图类，以及伴随演示者类。我还拥有一个拥有该窗口小部件的窗口的视图类，以及窗口视图的伴随主持人。窗口操纵窗口小部件，所以我需要窗口呈现器与窗口小部件主持人进行通信。想象：

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

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

1. 的意见，构建自己的主持人，和window_view结构widget_view。但是，window_view在其构造函数中需要额外的参数，它不应该关心的参数，仅仅是实例化演示者。我也不确定window_presenter将如何访问widget_presenter。添加一个widget_presenter setter到window_presenter为window_view填写不感觉对我来说是正确的。
2. 消除两位演示者之间的通信线路。 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，每个插件是用自己的控制器的视图。我认为这篇文章谈到了世界的“形式”观点，每一个“形式”都是一个观点的集合，而且只有一个控制者或主持人。我认为MVP属于“形式”观点，因此通常每个表格都是一名主持人。