问题
I've been using the MVP pattern for a while with ASP.NET. I've stuck to the defined pattern of raising presenter events from the view.
It has struck me that I could expose methods in the presenter that the view could call directly.
Technically, using direct methods calls would require less code. The other benefit is that I tend to share presenters across multiple views that offer similar functionality. This means that sometimes some of the event handlers are forced to be registered in a view, only to comply with the shared presenter's interface, but then are not used in that particular view at all.
A example of this would be a diary view, that in one view allows you to cancel an appointment, and in another it doesn't. The rest of the presenter events for loading the data, and saving an appointment are used in both. I don't want to write two separate presenters that almost offer the same functionality.
I'd like to hear what others think who are actively using MVP. Are there any reasons you can think of why direct method calls from the view to the presenter are bad in MVP?
回答1:
I use direct method calls, and don't see any worhtwhile reason to be defining events on the presenter. What you are using with events is called I believe "Observing Presenter" style. It does offer complete decoupling of View from Presenter, but with added complexity.
回答2:
If your view calls the presenter directly, then it would be tightly coupled like in mvc. I don't understand why some frameworks take this approach as opposed to raising events on the view.
回答3:
We can write an interface which contains all methods that we want to call from view. Presenter will implement this interface. We can then pass instance of this interface to view, and view can call methods on this interface. This will reduce coupling between two.
来源：https://stackoverflow.com/questions/2203906/mvp-should-views-be-able-to-call-presenter-methods-directly-or-should-they-alw