MVP In Silverlight/WPF: Conclusions

18 commentsWritten on August 8th, 2010 by
Categories: MVP In Silverlight/WPF

Note: This post is part of a series. You can find the introduction and overview of the series here.

We've (finally) reached the end of this series. As i mentioned before, this series was a response to a lot of the criticism that i received for my own critique on MVVM. Obviously, if you're going to dish it out, you have to be able to take it as well. And i did. I honestly can't even care about criticism on my work as long as i believe in what i do. But what did tick me off a lot by those reactions was the lack of willingness to at least try and think about what i was saying. A lot of people (particularly in the .NET world) are completely unwilling to invest just a little bit of time and effort in reading something and trying to understand it. They just want to glance over a post until they see a little bit of code and they'll often base their opinions solely on that. Unfortunately for them, they usually miss the appropriate context due to their laziness and they either won't get it, or won't understand the difference with what they already think they know.

People wanted code, so i showed them code. I also provided all the context in the world to go along with that code, and i can only hope that people took (or will take) the time to let it all soak in. If, after that, they still disagree with what i'm saying, then at least their opinion will be based on something more than just a quick glance over a post.

Other than that, i don't really have a lot more to say about the whole thing. If you're not convinced by the merits of the approach i've shown by now, nothing i can say in this post will change your mind about it either. And again, there's absolutely nothing wrong with disagreeing with this, as long as you show willingness to learn and put in some effort. That's all i can ask for.

« MVP In Silverlight/WPF: Automated TestsUsing Agatha’s Client-Side Caching »

This entry was posted on Sunday, August 8th, 2010 at 10:48 and is filed under MVP In Silverlight/WPF. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • Alex Simkin

    Davy,

    Thank you for yet another great series.

  • http://dmartin.net Dan Martin

    Thanks for the time and effort. That was a great series of posts.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #660

  • http://randallbits.com Randall Sutton

    Great series. I appreciate all the effort and ideas you have shared. I share your same feelings about MVVM, and prefer the MVP approach.

  • Alwin

    Hey Davy, first of all thanks for the posts. They give me good insight in how you think about development in Silverlight.

    I’m currently ‘porting’ your example to Caliburn Micro, mainly to see the differences in the approaches (and there are many). For a future project, I’m trying to find out what I personally find the preferable way to do development. Are you interested in seeing the port when I’m finished?

  • http://davybrion.com Davy Brion

    @Alwin

    sure :)

  • Alwin

    You can find the ported client here:
    http://easy-upload.nl/f/wDAN9uGH
    It is using Caliburn.Micro. Sorry, no unit tests…

    This was the first time I worked with Silverlight or WPF, so I learned plenty of new things.

    Agatha works really good and is easy to use.

    What I like about the caliburn port: you don’t have any view interface or code behind, you just have a view and a viewmodel. The view model is a representation of the logic of the application. The view binds both the data and the actions to this model.

    But the viewmodel now does to much. I would like to split it up in a VM (like your binding model?) and a presenter. But instead of a view interface and code-behind, caliburn-like conventions can wire up buttons to action. The structure in Effectus appeals to me: http://ayende.com/Blog/archive/2009/12/19/effectus-building-ui-based-on-conventions.aspx .

    An other option is the structure in Alexandria (http://github.com/ayende/Alexandria). Here you just have a viewmodel, but a lot of logic is not in the viewmodel, but in the message consumers. Maybe I can use Agatha to mimic the service bus that is used there. Then the view model sends requests, but does not handle the response itself.

    All in all, I think that only having a view and an view model is too little separation. There are different options to split the view model up, but I need to play some more to find out which way is most comfortable for me.

    Of course, your input and opinions about the port is always welcome.

  • http://davybrion.com Davy Brion

    @Alwin

    thanks for this port :)

    I agree that the ViewModel does too much, and it’s a good illustration of why i don’t like MVVM

    Also, i still really don’t get the point of trying to avoid any kind of code in the code-behind. Defining everything in XAML is indeed possible, but i just don’t think it’s such an important goal.

    cleaner separation is more important than avoiding all code in the code-behind IMO :)

  • Juanma

    Great series, Davy!

    Just one question. In this small sample there is no screen navigation, do you have an “standard” way to do it? Something along the lines of ScreenCoordinator/ApplicationShell of Jeremy Miller?

  • http://davybrion.com Davy Brion

    @Juanma

    It’s not in the example because it wasn’t needed and it’s not important to the discussion of going with MVVM or MVP.

    but we typically have some kind of navigator component which closes the current screen (you’d provide an optional way to override that of course) and displays the new one. There’s nothing special about it though.

    • Brevin

      so normally you would write that navigator component to the Presenter? and querystring is the common way to pass data? sorry for this basic question

      • http://davybrion.com Davy Brion

        yeah, the Presenter would communicate with the Navigator

        in case of web development with something like Web Forms, passing data around with querystring parameters is often sufficient, unless its sensitive data

  • Brevin

    thanks for your greate posts.
    I have a little question about class BindingModel,

    can it be non-generic, because it seems strange to write a class like :UserGroupDetailBindingModel : BindingModel

    • http://davybrion.com Davy Brion

      the reason it’s a generic class is to enable the usage of Expressions for the NotifyPropertyChanged stuff

      it makes the class definitions clumsy, but it removes the need to use strings for property change notifications

      • Brevin

        if so , why not write the code like following:
        public class MyTest
        {
        public string TestProperty { get; set; }
        public string ShowMyResult(Expression<Func> expression)
        }
        I mean set class name as the param for Expression. thanks

        • http://davybrion.com Davy Brion

          i think you don’t get automatic compiler inference from that

          we specifically wanted something like NotifyPropertyChanged(m => m.MyProperty) without having to specify a generic type every time

  • Peter

    Very interesting series!! When I first started implementing the MVVM pattern, the first thing that was brought up was “Where do we put common data validation, manipulation, etc?”. Validation and such being put in the model seemed awkward, to me at least. While putting it in the viewmodel was inefficient primarily because so many other things use the same logic. So to resolve this,  I ended coming up with a concept similar to what you have presented here but I feared that naming conventions would prompt the same sort of response you saw here, or worse from people who couldn’t quite get past names. To resolve this issue, I simply figured a better naming scheme was required. By mixing terminologies from DDD and MVVM, Domain  - DomainModel – ViewModel – View (DMVM) was born! 

    Domain(really Entities/Repositories) provide access to and represents domain layer data.
    DomainModel provides domain layer logic and validation(is this valid data for this property?).
    View provides a presentation to the user.
    ViewModel provides view layer logic and validation(can the user click that button?).
    A duality of sorts with the domain representing data, and the view.. well how we view it ;)

    I think this this made it simpler to grasp by separating not only what area they are responsible for (Domain = business logic, View = UI Logic) but also their representation (Domain = backend, View = UI).

    In conclusion, awesome series, great ideas, and you have a new reader :)

  • http://www.geekswithblogs.net/jboyer Justin

    Nice series. I enjoy reading different methods of doing things and am not as closed minded as some. Not sure if I am 100% sold on MVP just yet but I will let it settle and see how I feel about. If anything it puts another arrow in my quiver of design possibilities. Love the validation by the way. 

Meta

Recent Posts

Categories

Archives