被动视图模式：组件之间的通信
我将每个 MVP 三元组视为一个独立的组件。以View实现了IView接口为例，Presenter当然只能通过IView知道View。
我可以使组件尽可能地可重用。 现在我必须将这些 MVP 组件组合起来形成一个应用程序。我想知道使这些组件尽可能分开的良好做法是什么。但当然我需要让他们互相沟通/反应。
我可以让 IView 暴露给其他人的 Presenter 吗？或者我应该让演示者在不了解底层视图的情况下相互交流？
谢谢
I treat each MVP triad as a isolated component. With the View implements a IView interface for example, the Presenter only know the View thru IView of course.
That what I can make the component as reusable as possible.
Now I have to combine those MVP components to form an application. I am wondering what the good practice is to keep those components as separated as possible. But of course I would need to have them communicate/react to each other.
Can I just make the IView exposed to the other's Presenters? Or should I just let the presenters communicate with each other without knowing about the underlying Views?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 MVP 中，我将演示者视为活动的协调者。因此，它们是构建应用程序的自然选择。
将演示者的视图暴露给其他演示者打破了 MVP 模式中的封装理念。虽然它不会降低暴露其视图的组件的可重用性，但它确实会降低使用另一个组件视图的组件的可重用性，因为它增加了组件的依赖性。
所以我会把观点保密给演示者，只让演示者互相交流。
详细阐述回应评论
当我说将视图保留给演示者时，我的意思是私有：除非通过演示者的调解，否则不会暴露于外界。当然，演示者可以向外界公开方法，这将导致其操纵其视图。如果演示者通过接口执行此操作，它实际上可能使用自己的视图作为接口实现的委托，但是 - 与您的提议相反 - 演示者将内容委托给视图，而不是相反。
这样做可以确保或至少使所有交互逻辑更有可能保留在演示者中，并且不会散布在演示者和视图中。
视图只能由其呈现者操纵。当然，现在您可以在多个演示者中重用视图，但视图的实例只能由实例化它的演示者来操作。如果直接公开它（即使通过整个或部分接口），您就开始必须处理可以由多个演示者操作的视图，并且不再有单个演示者控制该视图。
我在视图中拥有的唯一代码是向其演示者通知用户已执行的操作（在某些 MVP 讨论中也称为用户手势）。由演示者决定如何处理。我还将有关启用/禁用哪些控件以响应演示者而不是视图中的用户选择的所有逻辑。这不仅将所有交互逻辑保留在演示器中，而且还有助于创建可单元测试的用户界面（表单）。
In MVP I see the presenters as the orchestrators of activity. As such they are the natural choice on which to base the composition of an application.
Exposing the view of a presenter to other presenters breaks the idea of encapsulation within the MVP pattern. While it doesn't reduce the reusability of the component exposing its view, it does reduce the reusability of a component making use of another component's view as it increases that components dependencies.
So I would keep the views private to the presenters and only let the presenters communicate with each other.
Elaboration in response to comment
When I say keep the view private to the presenter, I mean private: not exposed to the outside world except through the mediation of the presenter. Of course the presenter can expose methods to the outside world which will cause it to manipulate its view. If the presenter does this through an interface, it may actually use its own view as a delegate for the interface implementation, but - contrary to what you are proposing - the presenter delegates stuff to the view and not the other way around.
Doing it this way ensures, or at least makes it a lot more likely that all interaction logic stays within the presenters and does not get littered throughout presenters and views.
A view should only be manipulated by its presenter. Now of course you can reuse views in multiple presenters, but the instance of a view should only be manipulated by the presenter that instantiated it. If you expose it directly (even through whole or part interfaces), you start having to deal with a view that can be manipulated by mulitple presenters and no single presenter is in control of the view anymore.
The only code I have in the view are the notifications to its presenter of what a user has done (also known as user gestures in some MVP discussions). It is up to the presenter to decide what to do about it. I also keep all logic about which controls to enable/disable in response to user selections in the presenter and not in the view. That not only keeps all interaction logic in the presenter, but also helps towards creating unit-testable user-interfaces (forms).
编排演示者的一个好习惯是使用事件总线。
演示者注册到总线并监听他们需要做出反应的事件。
其他演示者在公共汽车上抛出事件，让可能的目标知道，什么
他们刚刚做到了。
消息应该基于问题领域，而不是技术
（例如“创建产品 123”）
很好的例子是 gwt mvp建筑学
和较新版本。
a good practice to orchestrate the presenters is to use an event bus.
presenters register to the bus and listen to events, that they need to react to.
other presenters throw events on the bus to let possible targets know, what
they just did.
The messages should be based on the problem domain, not technical
(e.g. "product 123 created")
a good example is the gwt mvp architecture
and the newer version.