Search code examples
wpfmvvmseparation-of-concerns

In MVVM, who is responsible for displaying other views, the ViewModel or the View?


Simple question in regards to a navigation pane like the one used by Outlook.

In MVVM, who is responsible for displaying other views, the ViewModel or the View?

It seems silly to put that code in the ViewModel when the View events can handle calling other views. The ViewModel does enable/disable and show/hide the navigation items as needed.


Solution

  • The ViewModel is responsible for view state. If whatever action the user performs happens to modify the view state, then the code for that action belongs in the view model.

    I like the MVVM pattern because of databinding, but I like databinding because it allows me to structure my code in a way that makes it easy to unit test most of my code. A big part of that structure is putting view state in one set of classes and model state in another.

    I think that many times that people try to implement MVVM, they're really implementing a model-view relationship solely for the purpose databinding. That's fine, because there's no reason to maintain abstractions if they don't provide you with a clear benefit.

    So, the answer to your question is what are you trying to achieve with your view models?

    Databinding? Put the code wherever you feel like it.

    Testability? Abstractions that provide separation of concerns? A model that is pure and free from view baggage?

    Then put it in the view model.