What's the best way to implement clean UI functionality in WinForms while maintaining a decent decoupled architecture?

Question

I tend to implement UI functionality using fairly self-documenting void doSomething() methods, i.e. if the user presses this button then perform this action then enable this list box, disable that button, etc. Is this the best approach? Is there a better pattern for general UI management i.e. how to control when controls are enabled/disabled/etc. etc. depending on user input?

Often I feel like I'm veering towards the 'big class that does everything' anti-pattern as so much seems to interact with the 'main' form class. Often, even if I'm including private state variables in the class that have been implemented using a relatively modular design, I'm still finding it grows so quickly it's ridiculous.

So could people give me some good advice towards producing quality, testable, decoupled WinForms design without falling into these traps?

Answer 1

You can try MVP if you want to put the logic of the UI in a separate class..

In model view presenter just as Martin Fowler or Michael Feathers say, the logic of the UI is separated into a class called presenter, that handles all the input from the user and that tells the "dumb" view what and when to display. The special testability of the pattern comes from the fact that the entire view can be replaced with a mock object and in this way the presenter, which is the most important part, can be easily unit tested in isolation.

Answer 2

using the MVP pattern is pretty good with winforms.

have a look at http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf