Asp.net MVP-视图应该能够直接调用presenter方法，还是应该始终引发事件？

我已经在ASP.NET中使用MVP模式有一段时间了。我坚持从视图中引发演示者事件的既定模式

我突然想到，我可以在presenter中公开视图可以直接调用的方法

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

例如日记视图，在一个视图中允许您取消约会，而在另一个视图中则不允许。其余用于加载数据和保存约会的presenter事件都在这两种情况下使用。我不想写两个几乎提供相同功能的独立演示者

---

我想听听其他积极使用MVP的人的想法。在MVP中，从视图到演示者的直接方法调用不好有什么原因吗？

我使用直接方法调用，但没有看到任何WorhTime原因在演示者上定义事件。你在活动中使用的是我相信的“观察演讲者”风格。它确实提供了视图与演示者的完全分离，但增加了复杂性。

如果您的视图直接调用演示者，那么它将像mvc一样紧密耦合。我不明白为什么有些框架采用这种方法，而不是在视图上引发事件。

我们可以编写一个包含我们希望从视图调用的所有方法的接口。演示者将实现此接口。然后我们可以将这个接口的实例传递给view，view可以调用这个接口上的方法。这将减少两者之间的耦合。

因此，如果我没弄错的话，你是说这种模式有几种口味，你可以根据自己的喜好混合搭配。我真正感兴趣的是，为什么通过事件完全解耦可能被视为更好的选择。是出于可测试性的原因吗？方法调用感觉像一个需求，而事件感觉像一个请求。我对我使用的模式很满意，但有时我认为重新评估这些架构决策是很好的！实际上，您使用的模式可能会使测试复杂化，但您已经完全将视图与演示者分离。是的，有多种口味，主要的是被动查看和监控控制器。你能回答吗？