How you’re writing WinForms apps – The results

Last time I asked the question “How are you building WinForms applications?” just to get a sense of how everyone else is doing things.  Here’s my tabulation of results with some comments below.  I had to apply some interpretation here, so take the numbers with a grain of salt.  Besides, it’s also a little bogus to tabulate because I’ll use a combination of Passive View, Supervising Controller, and Presentation Model within the same application depending upon the screen.  Plenty of you said the same.

  1. Composite Application Block:  4

  2. Presentation Model or Model-View-ViewModel:  5

  3. Passive View (I’m including Presenter First in this bucket):  8

  4. Supervising Controller:  11 

  5. Legacy Code ported from VB6 that’s not my Fault!:  6

plus one vote for Wendy‘s View to Command wiring.

Lots of folks doing Model centric validation.  I was pleasantly surprised by that, but shouldn’t have been.


The decisions seem to be based on the logical things.  If you trust data binding or at least think it’s a time saver you’re more likely to choose Presentation Model or Supervising Controller.  If you’re paranoid about test coverage, you pick Passive View. 

If you ported from VB6 you’re out of luck.  When I was coding VB6 I didn’t have a clue about View/Controller separation, and I’d bet the mass majority of my peers were in the same predicament there.


Next time, I’m going to try to compile a list of what everybody thought was hard and see if I can connect some links and patterns to some of it.  I was glad to see I wasn’t the only person unhappy enough with Data Binding to go their own way.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Mark Lindell


    I have to disagree as well based on my experiences.

    I’ve been prototyping a large data visualization project in WPF and the performance has been incredible! I’m accomplishing things with WPF that would NOT BE POSSIBLE by my talent in GDI or using Direct X.

    I’ve been using Infragistrics controls for WPF.

    I must admit, I don’t use the beta designers VS2005 or beta 2008. I hand code the XAML to assist in groking WPF.

  • Kent Boogaart

    @Derick. I don’t think any WPF dev would deny that there’s a significant learning curve to it. However, I can promise you – my personal opinion – that WPF brings many benefits to application developers once you grok it.

    Did you try running existing WPF samples on your machine to check whether they had performance issues? To me, 15-20 seconds sounds like something may be wrong with your installation / hardware / code. Trying an existing sample would at least rule out your code.

  • Derick Bailey

    WPF is a giant hunk of crap, at the moment. (my personal opinion) and is not ready for prime-time use, by any means.

    I tried implementing it for one of the most simple scenarios I could think of, in a recent project. it tooks two weeks to get a panel bar created and working (there are no good control suites for WPF, that i know of, yet) and the end result took 15 to 20 seconds to load the form, every time. I switched it out for a Telerik based standard winform in 2 hours and the form takes about 2 seconds to load.

  • Florian Krüsch

    It would be interesting to hear what people answer if you were asking for WPF.

  • Derick Bailey

    I don’t understand the issues with Databinding being so troublesome… can you elaborate on the issues?

    My typical use of databinding is that I have IList collections and I assign them as the datasource in my view. i can still unit test against the presenters that load up the IList… for complex databinding scenarios (where I need to actually update the list and have it reflected in a grid, etc), I wrap my IList inside of an IBindingList when i send the list to the view:

    public IMyView.MyMethod(IList whateverCollection)
    bindingList = new BindingList(whateverCollection);
    myGrid.DataSource = bindinglist;

    from there, i can update the original IList collection from within my presenter and it shows up in the view automatically.