5

I am trying to understand MVVM from last two weeks, but still have lots of confusion understanding it.

I have started Windows Phone 8 development recently.

My understanding of MVVM,

M = Model means data, what is specifically means is Model should be treated as struct of C language. It will only have properties or member variables (objects). It knows nothing about View and View Model.

V = Plain XAML. There should be only one way of binding and that is using DataContext.

VM = View Model is model for view. VM uses M to keep its data (using Containership), and VM have responsibility to save data in DB or to fetch data from db. DB interactions should happen in VM. VM should implement INotifyPropertyChanged, because it is responsible for saving and fetching of data.

Kindly, suggest I have wrong concepts regarding MVVM.

Pranit Kothari
  • 9,721
  • 10
  • 61
  • 137
  • 1
    `DB interactions should happen in VM` I usually prefer to put this kind of logic in a service layer, which gives at least two benefits: that logic can be shared between all the VMs, and it allows the VM to be focused on a data-translating role. – Kevin Gosse Jan 22 '14 at 07:09
  • 2
    Otherwise, I don't see anything wrong with your description of MVVM. Can you precise what confuses you? Also keep in mind that there's as many different interpretations of MVVM as there is apps. That's why it's called a *pattern* – Kevin Gosse Jan 22 '14 at 07:11
  • @KooKiz My confusions are, 1. Should 'modle' be treated as struct (conceptually), 2. Should VM only implement 'INotifyPropertyChanged' – Pranit Kothari Jan 22 '14 at 07:14
  • 2
    The purest is perhaps to only have INotifyPropertyChanged in Vm, implementing it in the model can save a lot of code though. Also it is not view specific, so imo implementing it in the model is good. – Johan Larsson Jan 22 '14 at 07:21
  • I totally agree with @Johan Larsson, `INotifyPropertyChanged` must be in the model, ViewModel can implement any interface that does not violate the principle of MVVM. In VM is better to leave `IDataErrorInfo` implementing interfaces, and the like. And yet, your opinion on MVVM good, I did not notice flaws. – Anatoliy Nikolaev Jan 22 '14 at 07:33
  • There's a big flaw... ***V = Plain XAML*** Nope. **V** is the view, which is solely concerned with rendering data to the user and handling input. That can mean codebehind, which is perfectly fine. It shouldn't do any business logic, but UI logic is okay. –  Jan 22 '14 at 16:30
  • http://stackoverflow.com/questions/5421874/basic-concepts-of-mvvm-what-should-a-viewmodel-do?rq=1 Here is a Link that explains "MVVM" in a very precise level. Hope this helps you!!!!! – Abhinav Sharma Jan 22 '14 at 07:40

3 Answers3

7

Everything you've said is technically correct, but I'd try to approach the design pattern in a more abstract way and think about what it's trying to solve. MVVM is trying to solve the problem of providing separation between the view and model as well as providing two-way binding (i.e. pulling data from a model and presenting it, as well as taking user input and saving that back to the model).

Most patterns will want to separate the View and the Model, so that's still the same in MVVM, but what is more murky is how to convert/format the data for display to the user, and how to convert user input into your model. In many MVC frameworks, the presentation of model data in the view is handled pretty well, but you're usually on your own for taking user input and converting back into the model cleanly. MVVM aims to handle both.

Microsoft has chosen to do that using things like DependencyProperty, ICommand and ValueConverters. The basic idea is that your View will only be loosely attached to the ViewModel through bindings, so in theory you could reuse ViewModels with other views. This goes the same in the other direction (this clean two-way binding is what makes MVVM different from MVC, for example) in that your VM can notify that a property has changed (that's why you must implement INotifyPropertyChanged), but the VM has no idea if a view is there to react or not. That makes it very straightforward when you want to reuse these components.

So knowing what MS is trying to solve with MVVM, you can hopefully better understand why things like INotifyPropertyChanged exists or what ICommand is for and hopefully make good use of the MVVM pattern.

Michael Yoon
  • 1,606
  • 11
  • 9
3

I've been working with MVVM since 2008 and your explanation is mostly as I would explain it to someone who has not worked with MVVM or any MV* pattern before.

As Michael said the core thing is to separate the view from the logic as all MV* frameworks aim for but there are slight differences in how this can be achieved. With WPF came XAML which took databinding to a whole new level, now we could bind almost anything without a direct dependency to the data.

In MVC we have the controller which "tells" the view what to do and in MVVM the view listens to what the ViewModel has to say eg. the IsDirty property of the ViewModel indicates that the data has changed then the view has a way of visualizing this. It's not the ViewModels job of telling the view what to do, its the view that listens to changes in the ViewModel. This works the other way around by binding two way for input controls. The ViewModel does not know how this data came to be, it only dictates what type it should be.

When I try to explain more complex projects written in MVVM i divide ViewModels into two different sub types; WrapperViewModels, LogicViewModels.

  • WrapperViewModel: This is a ViewModel that is more or less just makeup on a Model. It contains properties that exposes the data together with PropertyChanged logic. It contains logic for exposing eg. FullName when the model only has FirstName and LastName etc. This VM can however be replaced by implementing INotifyPropertyChanged in the model, but it might not be the best approach in all cases.

  • LogicViewModel: These VM are the ones that contains the application logic. The MainViewModel which is the heart of the application is one example of these. If you see the application as a set of islands where each island is responsible for a part of the application this part usally has its own LogicViewModel

When it comes to the Model layer i usally say that the following logic resides in that layer; Data, DatabaseAccess, ServiceAccess, FileAccess. Essentially all code that has to do with stuff outside the application coming in or going out. I would not write any logic in the ViewModels that directly access anything other than Model objects and other ViewModels.

There are cases when MVVM tend to make some easy tasks overly complex. In these scenarios I would suggest looking into making a real control out of a view and viewmodel. Doing this makes it possible to reuse the control and have full control of the internals of it. Other things that simplifies MVVM development and are almost mandatory is the knowledge of the messenger/mediator pattern, Dependency Injection and Behaviors/Triggers/Actions/Attached Properties.

A thing that most people say is that the View should be pure Xaml, no logic what so ever. This is completely wrong in my opinion. Code/logic is allowed in the View as long as you follow the principle that the View should not know about the ViewModel logic. As log as the logic is purely for leveraging presentation it is OK but as soon as you have a reference to a ViewModel class you are on thin ice.

Christian Paulin
  • 81
  • 3
0

I tend to characterize MVVM in as a growth of Model View Presenter. In Model View Presenter, the Presenter takes the Model and builds a View. Change the model, and the view changes. MVP could not be simpler, which is why I start with it!

The ViewModel is replacement for the unidirectional Presenter: it's a state-tracking bidirectional equivalent. In addition to watching for changes to the model, it also watches events and changes to the View, and provides the glue and logic to update the model system.

This is a more generic answer removed from technological particulars, and hopefully it does a respectful job touring the idea.

rektide
  • 1,492
  • 13
  • 21