MVP In Silverlight/WPF Series

6 commentsWritten on August 1st, 2010 by
Categories: MVP In Silverlight/WPF

I recently criticized the MVVM pattern which pretty much every Silverlight and WPF developer has probably used by now. Reactions to that post were (as was to be expected) pretty varied. Quite a few people agreed with my statements. Others needed to see code to get a better idea of what i'm talking about. Others flat-out considered it (and my opinions in general in some cases) to be nonsense. Challenging the MSDN-recommended-way-of-development always seems to stir up emotions with a large group of .NET developers, but the fact of the matter is that it simply needs to be done if you think you've got a better alternative. Whether or not i'm actually right about it doesn't even matter. The whole point is that you should be aware of alternatives and that the approach you choose to follow is the result of an informed decision.

And that's why i decided to write this series instead of simply trying to back up my statements with a post that showed some code. It's pretty hard to back up architectural preferences with a little bit of code in a blog post. People will either complain that the example is too contrived, or that your example doesn't really illustrate the benefits of your architectural ideas and that it can be done much simpler. With this series, and its accompanying sample project (which i'll link to in a future post in this series), i hope to convince at least a few of you that the MVP approach can indeed be a much better choice over MVVM. I'm fully aware of the fact that plenty of 'typical' .NET developers will still criticize this series, the sample project and the approach that i'm advocating. And that's ok, really. We can all have our opinions and we can all develop our software the way we want to. And while i hope to 'convert' at least some of you, i'll already consider the whole thing a 'win' if i can just get a bunch of people to at least think about some of the things i'll talk about in this series.

These are the posts the series consists of:

  1. Architectural Overview
  2. Some Infrastructure Bits
  3. The Sample
  4. Implementing The Overview UserControl
  5. Implementing The Details UserControl
  6. Automated Tests
  7. Conclusions
  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #655

  • http://codedreams.blogspot.com/ Mike Strobel

    Great series, Davy. Not only have you and I come to the same conclusions about MVVM, but we have independently developed similar MVP variations as an alternative. I’ve been calling my MVP variation “PMVP”, as the model tends to expose more UI-centric properties and events than you would see in traditional MVP models. One of my primary tenets has been to keep logic out of the presentation model and in the presenter (where, IMO, it belongs). I even went so far as to say that the model should not perform its own validation, but should rely on a validator provided by the presenter. Your abstracted property validation doesn’t quite go that far, but aside from that, your architecture is virtually identical to mine. Keep up the good work!

  • Pingback: Stuff I’m Reading

  • Norman_mackay

    Davy,

    Thanks for posting this, I’ve been doing an R&D project into WPF and have
    been using WPF for a few years but realised the code behind approach won’t work like it does for Winforms for large LOB applications, in fact I had to fix up a Winforms
    project for the last 4 months where the developer tried to implement some kind
    of curious MVVM approach in Winforms, the result was truly horrendous.

    I’ve been looking at Prism4 as we have a large redevelopment using WPF, we have
    a large ORM model, there will be a container with 15-20 modules which are
    independent but must have basic communication with each other and the
    container, I did the proof of concept using interfaces and routed events which
    while worked well didn’t provide a clean approach for module communication. Prism
    does have some nice features for event brokerage etc but the data side seems
    clunky, our data service may be a WCF service to ORM layer or direct to the
    ORM layer but that’s not decided yet.

     

    Prism is not all things to all
    men, the creator admits that himself:

     

    “the overhead in implementing
    MVVM is “overkill” for simple UI operations. He also states that for larger
    applications, generalizing the View layer Becomes more difficult. Moreover, he illustrates
    that data binding, if not managed well, can result in considerable memory
    consumption in an application.”

     

    I read the other MVVM thread and
    you got a fair bit of stick, you should create another thread saying it’s still
    okay to use stored procedures in some cases for complex data retrieval, you’ll
    get some heated responses. ORM is another area that creates huge debate.

     

    It’s a always good to keep an
    open mind.

     

    Norman.

  • Ashok Gudur

    Great Series. I really liked the approach.

    I would like to know one thing. If I would like to enable the same API over a web service.
    How server side validation should be done then?  Should this be duplicated? 
    Shall we write all of those client side validations code again in server side?
    Is there anything we can do like in RIA services?

    Thanks
    Ashok Guduru

    • http://davybrion.com Davy Brion

      in my experience, the aim of reaching reuse when it comes to client-side validation is overrated and the pains that come along with trying to reach it are not worth the supposed gains of not having to ‘duplicate’ validation logic

      i usually go with this:
      all validation needs to be done server side
      *simple* validation can be done client-side

      if there is any duplication when it comes to client-side validation, it is typically so insignificant that it’s not worth trying to avoid IMO