I'm using the MVP pattern in a windows form app. I need to change a radio button on the view. I can do this by exposing a Boolean property on the view, but should I be using events to manipulate the view instead?
Using "plain language" analysis, I would say that "whether or not the radio button is displayed is a property of the view" and therefore use an actual property to communicate this to the View.
The other (technical) possibility would be to have a event on the Presenter, i.e. RadioButtonVisibilityChanged
, which is listened to by the View and passes the new visibility through the EventArgs
. This runs contrary to the View being independent and ignorant of the Presenter and therefore undermines the MVP pattern. I advise against such nonsense.
It's a matter of purity vs being pragmatic... and a bit of personal style. Shouldn't matter... events are just more work than normal methods but more decoupled. Personally
- I like to keep views decoupled or unaware of the presenters, hence Views communicate to the presenter by raising events. This eliminates the need for the view to have a reference to the presenter. Keep Views thin and dumb.
- The presenter on the other hand has a member reference to the view (and the model) usually. Hence it can talk to the view by making method calls via an interface (permits views to be substituted as long as they conform to the IView interface). e.g. In your case, Set_X_Option(eOptionEnum) would be a member of the IView Interface, which the presenter can then invoke appropriately.
However you could remove this IView dependency (presenter has reference to an IView, that needs to be instantiated and plugged in) as well by using events both ways... however I find that its too much work. The above scheme has never failed me... yet.
Typically the controller changes the view through properties and subscribes to events raised by the view to know about changes. Here's a nice example of MVP, even though in Asp.NET works basically the same for Windows Forms.