Question

我有一个表示窗口小部件的视图类，以及一个附带的演示者类。我还有一个拥有窗口小部件的窗口的视图类，以及一个附带的窗口视图的演示者。窗口操纵窗口小部件，因此我需要窗口展示器与窗口小部件呈现器进行通信。想象：

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

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

视图构建了他们的演示者，window_view构建了widget_view。但是，window_view在其构造函数中需要额外的参数，它不应该关注的参数，仅仅是为了实例化演示者。我也不确定window_presenter如何访问widget_presenter。为widget_presenter window_presenter添加window_view setter以填写对我来说感觉不对。
消除两位演示者之间的沟通线。 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属于“表单”视图，因此通常每个表单都有一个演示者。

model / view / presenter：presenter-to-presenter communication

1 个答案: