MVP - 应该能够直接调用演示者方法，还是应该始终提高事件？

我一直在使用ASP.NET的MVP模式。我坚持从视图中提出主持人事件的定义模式。MVP - 应该能够直接调用演示者方法，还是应该始终提高事件？

它让我感到震惊，我可以在演示者中暴露视图可以直接调用的方法。

从技术上讲，使用直接方法调用将需要更少的代码。另一个好处是我倾向于在提供类似功能的多个视图中分享演示者。这意味着有时候某些事件处理程序被迫在视图中注册，只是为了遵守共享的演示者界面，但在那个特定视图中根本不使用。

一个这样的例子是日记视图，在一个视图中允许您取消约会，而在另一个视图中则不会。其余的主持人事件用于加载数据，并保存预约用于两者。我不想写两个几乎提供相同功能的独立演示者。

我想听听别人认为谁在积极使用MVP。是否有任何理由可以想到为什么从视图直接调用方法的主持人在MVP中不好？

来源

2010-02-04 Junto

我使用直接方法调用，并没有看到任何worhtwhile理由定义事件发言人。您使用的事件称为“相信演示者”风格。它确实提供View Presenter的完全解耦，但增加了复杂性。

来源

2010-02-05 16:12:20 epitka

所以，如果我理解你是对的，你说这个模式有几种口味，你可以根据你的喜好混合搭配这些口味。我真正有兴趣知道的是，为什么通过事件完成解耦可能被认为是更好的选择。这是出于可测性的原因吗？方法调用感觉像一个需求，事件，一个请求。我对我正在使用的模式感到满意，但有时我认为重新评估这些架构决策是一件好事！ – Junto 2010-02-07 21:52:55

实际上，您使用的模式可能会使测试复杂化，但是您已将演示者的视图完全解耦。是的，有多种口味，主要口味称为被动视图和监督控制器。 – epitka 2010-02-08 03:21:26

你能否回答http://stackoverflow.com/questions/8851933/event-bubbling-and-mvp-asp-net？ – Lijo 2012-01-16 06:15:13

如果您的视图直接调用演示者，那么它将像mvc中那样紧密耦合。我不明白为什么一些框架采取这种方法而不是提出这个观点的事件。

来源

2010-09-14 04:09:49 Ant

我们可以编写一个接口，其中包含我们想要从视图调用的所有方法。演示者将实现这个接口。然后我们可以传递这个接口的实例来查看，并且查看可以在这个接口上调用方法。这将减少两者之间的耦合。

来源

2012-01-20 05:49:24

MVP - 应该能够直接调用演示者方法，还是应该始终提高事件？

回答

相关问题