Patterns, Practises, MVP and Winforms

  • Thread starter Thread starter Pete Hurford
  • Start date Start date
P

Pete Hurford

I'm all for adopting Patterns and Practises where applicable, and can easily
appreciate the value of the MVP pattern for simplifying a complex UI tier.

However I have yet to find a *good* working example of how one might achieve
this in a WinForms environment.

Can anyone recommend one?

Thanks,
Pete
 
In addition to Peter Duniho's comments, which in my opinion describe
MVC and could possibly serve to illustrate the differences between MVP
and MVC, MVP forces the discipline to completely separate your UI
implementation (the View) even from the UI logic that drives it
(Presenter). In this mode, the Presenter is "subscribed" to all the
events and controls the View. Paired with the inversion of control and
dependency injection it provides for pretty good separation of
concerns. This may be helpful if you ever need to put a different
"face" on your app, for example.

The folks at MS P&P that did Web Client Software Factory found another
benefit of the above combination - they are able to make their views
more testable by following that pattern (being able to unit-test
without the entire session context)

I found the following reading to be helpful, while I was going up the
learning curve of Microsoft's Smart Client Software Factory (SCSF):
http://ctrl-shift-b.com/2007/08/interactive-application-architecture.html
http://richnewman.wordpress.com/200...asic-pattern-introduction-to-cabscsf-part-24/

You can check how SCSF implements it, but it may give you a headache
due to the many other concepts intermixed in the factory.

Web Client Software Factory is somewhat simpler than the SCSF. I know
that you asked for WinForms, but if you do the relevant Hands-On-Labs
that come with WCSF you may be able to answer some of your own
questions about the MVP pattern.
 
Thanks Mr Arnold, having looked at the first two I think these are better
than anything I have seen to date.

Some comments:

I think he obscures things a little by shoving his interface in the same
place as his presenter - I'd keep them separate just to highlight the
difference.

That the view knows about (indeed creates) the presenter is not good, at
least from a purist viewpoint. In an ideal world I can conceive some kind of
factory which creates a view, creates the presenter, and marries the two such
that they never know about each other, only the interface.

But then you could quite reasonably raise the question of how on earth you'd
implement that, especially in WebForms, where it is basically the view that
is being loaded directly by asp.net. This is kind of where I was coming from
with my question - I wanted to see if someone had come up with a good
implementation which basically didn't start with the View.

That the view raises events is good, imo this is exactly how it should
happen. Note that none of the code in his view, except for the single line
where he creates it, refers to the presenter directly.

If I could work out a way where the view didn't even have to create the
presenter, then I'd be happy.

Thanks once again for the link.
Pete
 
Back
Top