locked
V/VM push or pull? RRS feed

  • Question

  • We are having a debate here regarding our View/ViewModel.

    Several of us are pushing for the View to be the controlling entity, communicating with the ViewModel as necessary to "pull" data.

    Several of us are pushing for the ViewModel to be the controlling entity, storing references to the key controls on the form as necessary to "push" data to them.

    It does not make sense for us to do both :-) so we will need to pick one or the other.

    Any thoughts on pros/cons to the two approaches?

    THANKS!


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 3:18 PM

Answers

    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 3:59 PM
  • I'm wondering about the context.

    I use MVVM with WPF.

    The binding handles transfer of data between the layers and although I suppose that makes the view sort of pull since it has the bindings in it.

    I'm guessing this is not WPF since that's so obviously the way to do it in WPF.

    I reckon that the controller needs to know too much about controls in the view if you push from the controller.  That probably makes testing and mocking impractical so I'd go with the view pulling.  I may of course be inherently biased because that's how I do it. 

    An alternative would be to have a mediator acting as an intermediate layer, but that's just overcomplicating it, right?

    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 4:08 PM
  • Its an old WinForms project.

    I see the current system as being very spagetti like with routines in the Controller updating different things in different parts of the UI.

    And...

    View: UI with the many custom controls.
    View/Model: Single class that catches events from the UI, performs any required global processing, and re-raises the events out for the controls to update themselves.
    Model: Set of business objects that take care of all of the business logic/calculations.

     

    For Windows Forms applications, this seems like a reasonable approach.  "MVVM" really needs the Data Binding capabilities of WPF to be successful - it's based on the amazing power WPF's data binding adds.  With Windows Forms, you don't really have access to this, so working in a more traditional MVP approach makes sense.  (That being said, there has been some work done to allow a more MVVM approach in Windows Forms via libraries like Truss, which is excellent BTW...)

    Here are some pro/cons I can see with your approach.

    Advantages:

    1. Most likely simpler logical layer, since you don't need to keep references to all controls.
    2. Easier to change the View layer, since the View layer is self-contained (if you want to change a control, it doesn't change the "ViewModel" portion, since the View is pulling its data across)
    3. More uniform model with WPF and MVVM - for future migration (if this is an issue).  MVVM basically does this, but uses WPF's data binding to "pull" and handle the updates for you, so you don't have to deal with that portion in your View.
    Cons:
    1. View becomes dramatically more complicated.  It now has to have an event processing layer to self-update.
    2. View gets tied to the ViewModel implementation.  (Instead of having the "controlling" logic in your middle layer, you're moving it to the View layer.)

    The main issue I have is the complication in the View - I worry that, with a complex model, the View may end up being filled with extra code, since you're basically trying to re implement WPF's data binding capabilities yourself, in the View.  This may be worse than having no separation, with a big UI - but it's difficult to tell.

    Perhaps, if you could use something like Truss combined with Windows Form's databinding, this could be worked around in a way that wouldn't cause the same issues.  It's tough without seeing the implementation to see where the real issues might creep up in this type of situation, though.

    As for the "events" being fragile - this isn't really something I'd worry about, at all.  Events in .NET are incredibly solid and reliable, so there really isn't any validity to this argument.  I've done some pretty crazy synchronization around events (including a fully featured rendering engine, at one point, that used events for all of the internal communication - had to handle thousands of events / second, and worked flawlessly).

     

    I will say, though - the one thing I really like about your approach is the simplification of the "logic" layer here - this would make the Presenter classes much, much simpler.  There is a HUGE advantage to this: your presenter class, which contains all of your application logic, would become testable without the UI in place. This is one of the biggest advantages to MVVM, and you'd be giving yourself this advantage too.  Your current model is flawed in this regard, since it's nearly impossible to effectively test your controllers, since they are so integrally tied to the View.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 9:24 PM

All replies

    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 3:59 PM
  • Yes, thanks for the links. We have all read *lots* of information on these patterns. But our interpretations on the pull/push issue are still an issue.

    Do you have any suggestions for the specific question regardubg push/pull?

    THANKS!


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 4:04 PM
  • I'm wondering about the context.

    I use MVVM with WPF.

    The binding handles transfer of data between the layers and although I suppose that makes the view sort of pull since it has the bindings in it.

    I'm guessing this is not WPF since that's so obviously the way to do it in WPF.

    I reckon that the controller needs to know too much about controls in the view if you push from the controller.  That probably makes testing and mocking impractical so I'd go with the view pulling.  I may of course be inherently biased because that's how I do it. 

    An alternative would be to have a mediator acting as an intermediate layer, but that's just overcomplicating it, right?

    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 4:08 PM
  • To add to this ... this link:

    http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/

    Basically presents the problem we are discussing. The first diagram shows both the pull approach (MVC) and the push approach (MVP).

    In the diagrams, it looks like MVVM is more of a pull approach ... but I was hoping for some "real world" experience on the best way to go.

    THANKS!


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 4:10 PM
  • Several of us are pushing for the View to be the controlling entity, communicating with the ViewModel as necessary to "pull" data.

    Several of us are pushing for the ViewModel to be the controlling entity, storing references to the key controls on the form as necessary to "push" data to them.

     

    Deborah:

     

    What framework are you using for your View/ViewModel?  (These terms are most common with Silverlight or WPF - but if you're using something else, the Pro/Con list changes dramatically).

     

    -Reed

     


    Reed Copsey, Jr. - http://reedcopsey.com
    Thursday, April 8, 2010 4:21 PM
  • I think there are good reasons for MVC being more suitable for web, MVP for winforms and MVVM for WPF.

    I lilke using MVVM for WPF.

    Not used MVP.

    MVC has a high cost associated with it compared to webforms and I don't really like it.  I think that MVC diagram is somewhat misleading.  Having said that there are different implementations of MVC where model to view might be right.   Someone told me it's been kicking round in the java community for years.

    Thursday, April 8, 2010 4:23 PM
  • Thanks, Andy.

    Yes, I don't want to make it more complex than it needs to be.

    It is a WinForms project that was recently migrated (by someone else) from VB6 and is rather a mess.

    It has one main form with a set of controls that change based on the menu ribbon you have selected.

    For example, a CustomerSelection control displays the list of customers. A CustomerDetail control displays the selected customer. A CustomerTransaction control displays the customer's transactions.

    Right now, there is a "Controller" that keeps everything updated. But it has instances of each of the controls in it and handles the updating. So it is rather "push"y.

    I was suggesting that the "Controller" instead use events to keep everyone aware of what was modified in each section. But the ex-VB6 team is concerned about event fragileness (is that a word?) So they are not very keen on the idea.


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 8:11 PM
  • Hey Reed -

    Its an old WinForms project.

    I see the current system as being very spagetti like with routines in the Controller updating different things in different parts of the UI.

    I like to see things a little "cleaner", where it would just send out a notification event and the controls would update themselves automatically.

    I started a prototype of this change, just to see how much effort would be involved. The prototype code now seems much more organized and easier to follow.

    But I want to put together a good pro/con list before presenting this to the team.

    THANKS!


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 8:14 PM
  • Hi Andy -

    Thanks for your thoughts.

    The prototype I just built for this is much more MVVM:

    View: UI with the many custom controls.

    View/Model: Single class that catches events from the UI, performs any required global processing, and re-raises the events out for the controls to update themselves.

    Model: Set of business objects that take care of all of the business logic/calculations.

    Thoughts?


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, April 8, 2010 8:18 PM
  • Its an old WinForms project.

    I see the current system as being very spagetti like with routines in the Controller updating different things in different parts of the UI.

    And...

    View: UI with the many custom controls.
    View/Model: Single class that catches events from the UI, performs any required global processing, and re-raises the events out for the controls to update themselves.
    Model: Set of business objects that take care of all of the business logic/calculations.

     

    For Windows Forms applications, this seems like a reasonable approach.  "MVVM" really needs the Data Binding capabilities of WPF to be successful - it's based on the amazing power WPF's data binding adds.  With Windows Forms, you don't really have access to this, so working in a more traditional MVP approach makes sense.  (That being said, there has been some work done to allow a more MVVM approach in Windows Forms via libraries like Truss, which is excellent BTW...)

    Here are some pro/cons I can see with your approach.

    Advantages:

    1. Most likely simpler logical layer, since you don't need to keep references to all controls.
    2. Easier to change the View layer, since the View layer is self-contained (if you want to change a control, it doesn't change the "ViewModel" portion, since the View is pulling its data across)
    3. More uniform model with WPF and MVVM - for future migration (if this is an issue).  MVVM basically does this, but uses WPF's data binding to "pull" and handle the updates for you, so you don't have to deal with that portion in your View.
    Cons:
    1. View becomes dramatically more complicated.  It now has to have an event processing layer to self-update.
    2. View gets tied to the ViewModel implementation.  (Instead of having the "controlling" logic in your middle layer, you're moving it to the View layer.)

    The main issue I have is the complication in the View - I worry that, with a complex model, the View may end up being filled with extra code, since you're basically trying to re implement WPF's data binding capabilities yourself, in the View.  This may be worse than having no separation, with a big UI - but it's difficult to tell.

    Perhaps, if you could use something like Truss combined with Windows Form's databinding, this could be worked around in a way that wouldn't cause the same issues.  It's tough without seeing the implementation to see where the real issues might creep up in this type of situation, though.

    As for the "events" being fragile - this isn't really something I'd worry about, at all.  Events in .NET are incredibly solid and reliable, so there really isn't any validity to this argument.  I've done some pretty crazy synchronization around events (including a fully featured rendering engine, at one point, that used events for all of the internal communication - had to handle thousands of events / second, and worked flawlessly).

     

    I will say, though - the one thing I really like about your approach is the simplification of the "logic" layer here - this would make the Presenter classes much, much simpler.  There is a HUGE advantage to this: your presenter class, which contains all of your application logic, would become testable without the UI in place. This is one of the biggest advantages to MVVM, and you'd be giving yourself this advantage too.  Your current model is flawed in this regard, since it's nearly impossible to effectively test your controllers, since they are so integrally tied to the View.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by DeborahKMVP Friday, April 9, 2010 12:51 AM
    Thursday, April 8, 2010 9:24 PM
  • Thanks Reed. I appreciate your thoughts.

    It appears that there are a limited number of events that need to be generated, even though they are in many different places. For example, there are three different places in different user controls that can cause a change to the displayed customer. So a single CustomerChanged event broadcast out to all of the user controls handles this nicely.

    But you are right about the current code not being very testable. The prototype using MVP should be easy enough to test because now it just generates events. So the test code only really needs to determine if the event was generated.

    I am talking to the developers tomorrow and we'll see how it goes.

    Thanks again!


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Friday, April 9, 2010 12:51 AM
  • Good luck with your project.

    Obviously, from a paragraph of description it's not possible to get more than just a flavour of how  a project works.

    There might be some value in switching to wpf though.  MVVM works well with WPF, it addresses some of your high level issues.  Plus if you're pushing to do a second conversion maybe you will find it easier to justify if the toolset is changing as well. 

    There again, the developers involved may not like the idea of learning another toolset. Some do, some don't.

    Friday, April 9, 2010 8:18 AM