and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.
If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see.
If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all.
I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right.
We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.
Comments
and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.
There's no silver bullet method.
If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see.
If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all.
I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right.
We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.
Traditionally(on desktop applications) the model was injected into the view, then actions(save, delete, buttons etc) were performed on the controller.
However the way Apples IBOutlet system works, makes this difficult. You link up the UI to fields on the controller.
The first significantly reduces code size.