locked
ViewModel, Controller & Code-Behind RRS feed

  • Frage

  • Hi,

    After reading (more than) a few articles about the MVVM pattern, I still have thought regarding it's structure - I understand the need for ViewModel objects as view-specific wrappers for the Model entities layer.

    The problem is, that according to many bloggers the view-specific commands implementation should also be inside the ViewModel, but the ViewModel IMO is Data-centric entity so by adding business logic to it - will break the whole SoC idea.

    So the question is where should I put the view-specific commands logic. 

    My idea is to implement them inside the view's Code-Behind while specific cases where the logic is known to be shared amongst more than one view, it would be implemented in Controller classes and only be called from the view's Code-Behind.

    The thing is, at first I thought all commands logic should be implemented in Controllers, but I started seeing most commands were very thin (simply call the WCF Service) and mostly very view-specific, making the Controllers a overhead both in performance and in coding\support.


    What do you think?


    Montag, 11. April 2011 07:47

Antworten

  • I appreciate the importance of unit-tests, but why is the view's code-behind less testable?

    Obviously depending on the situation it still may be important to test, but it can be a little more difficult to do so. A ViewModel should be very easy to instantiate on its own, set some properties, and verify that a value is what you want it to be. A view is part of a larger system, may popup a dialog, display an animation,etc, etc. Testing something like that is a little trickier to automate.

    operations might require user confirmation or notification system as part of the business logic.

    That's a tricky situation where your business requirements include some sort of human interaction, i.e. user must confirm yes threee times. Honestly, I think for cases like that it would be really helpful if there was some nifty new functionality in the runtime that facilitated that type of requirement. Hopefully that's the type of thing that some big brains within Microsoft are working on. 

    Dienstag, 12. April 2011 12:35

Alle Antworten

  • Hi,

    Views can communicate with presenters and services in a loosely coupled fashion by using commands.

     

    Dienstag, 12. April 2011 02:21
  • I'm not sure I understand your response...

    Dienstag, 12. April 2011 03:46
  • Hi,

    So the question is where should I put the view-specific commands logic.

    Put in ViewModel.

    Dienstag, 12. April 2011 04:03
  • I'm not sure I understand your response...

    That's not important. Getting a couple points with gibberish is.

    I'm no expert in regards to MVVM, and it seems to me it's one of those areas where people can get way too religious. If I strikes me that I'd be doing tons of work to force it into the ViewModel, I don't bother and leave it in the view. My real goal though is testability. I don't care how the user selected option B, I just want to ensure that if they do, they won't be able to perform action X.

    Dienstag, 12. April 2011 04:06
  • I'm not sure I understand your response...

    That's not important. Getting a couple points with gibberish is.

    I'm no expert in regards to MVVM, and it seems to me it's one of those areas where people can get way too religious. If I strikes me that I'd be doing tons of work to force it into the ViewModel, I don't bother and leave it in the view. My real goal though is testability. I don't care how the user selected option B, I just want to ensure that if they do, they won't be able to perform action X.

    Jack,

    Did you ever read the post at this time?

    I thought, The question may be deal with about some kind of Container, But I don't know what kind.

    If yes, We should efficient code. UGH.

    Dienstag, 12. April 2011 05:28
  • That's not important. Getting a couple points with gibberish is.

    ;)

    I appreciate the importance of unit-tests, but why is the view's code-behind less testable? If it's because the UI-related code inside it, shouldn't this changes be part of the test as well?

    And what about notifications - it is reasonable to assume many (considering error handling - all?) operations might require user confirmation or notification system as part of the business logic. when the command is in the ViewModel, such tasks are harder to implement (they are possible using some sort of delegation or event mechanism between the ViewModel and the Code-Behind), and IMO just feel funny.


    Thanks for the honest reply, and I'd really like to hear your comments about this (sorry if this is a 101 questions, it just seems like everyone take for granted the reasons for some of this design choices without the need to explain them)

    Dienstag, 12. April 2011 05:46
  • Did you ever read the post at this time?

    An interesting attempt at jujitsu and two more points, well done. Yes, I read the post, and I gave an intelligible response that attempted to address his concern regarding the appropriate location for certain code. Hence, his follow up question.

    Dienstag, 12. April 2011 12:26
  • I appreciate the importance of unit-tests, but why is the view's code-behind less testable?

    Obviously depending on the situation it still may be important to test, but it can be a little more difficult to do so. A ViewModel should be very easy to instantiate on its own, set some properties, and verify that a value is what you want it to be. A view is part of a larger system, may popup a dialog, display an animation,etc, etc. Testing something like that is a little trickier to automate.

    operations might require user confirmation or notification system as part of the business logic.

    That's a tricky situation where your business requirements include some sort of human interaction, i.e. user must confirm yes threee times. Honestly, I think for cases like that it would be really helpful if there was some nifty new functionality in the runtime that facilitated that type of requirement. Hopefully that's the type of thing that some big brains within Microsoft are working on. 

    Dienstag, 12. April 2011 12:35