MVVM View first VS. ViewModel first

25 בJanuary 2016

אין תגובות

Since early times UI developers has merchandise with the purpose of MVVM
It is hard to judge what is better way to develop with,

 in this post I will try to demonstrate they both,  and compare a little but definitely not to have a statement of what is right,

–  The term of ViewModel evolution 1:
Is it a Model translation for presentation layer,
So when we writing this ViewModel class we actually relay either on a real model like  a physical entity or virtual one like other class

 –  The term of ViewModel evolution 2:
In MVVM CodeBehind is prohibited, there for every reaction for user actions will be in the ViewModel instead of the CodeBehind.

The main different of course will be on implementation,
in View first we writing views than provide each view a ViewModel as Datacontext, and the ViewModel is in charge as mediator between View and Other Application layers,
in this case the View term is a screen, which contains some app data and has only one ViewModel connected.

in ViewModel first we have a lot of ViewModel blocks, in general every presented object (meaning every application type that have a reason to show got a new layer called ViewModel) got his ViewModel with correlation to Model,  than with DataTemplate we generate an appropriate view for this ViewModel,
now , the views become shorter with much more Item Presenters, along with a lot of DataTemplates  per each viewModel item.
The most technical different is like this:
<ContentControl  Content=”{Binding MyProperty}”/>
While MyProperty is a ViewModel type, than using a Datatemplate the ViewModel can draw itself.

This allow us better separation, independence, reuse, and even provide much more navigation options.
But, ViewModel first is more dev time,
Yet, for big apps it getting benefits.

Now, in many applications those two methods get involved with each other,
And a complex of ViewFirst and ViewModel first is in action,
It is not necessary  a bad thing.  Mainly things of ViewLogic like states of a control whan came into a ViewModel looking bad, that why we found many times viewFirst with ViewModel per View, than viewModels per Model with control games between them.
As for me I use them both with depends of project requirements,

 I even choose many times when a Complex Data is mixed to work with my own MV* pattern which is ViewFirst than the ViewModel is actually the view-Logic what left us with clean code and full separation between View and Model, but together with DTO types who can be treated as ViewModels types of the ViewModel first system.
In this case it is no more a Model-View-ViewModel, but Model-View-ViewLogic-ViewModel pattern.
This pattern is relevant for big data involved  for example:
Model = Class Car (with red color while color is just an Enum)
View = Car Presentation tier (red icon)
ViewLogic = the logic behind he view, like respond to user actions.(mouse hover the icon)
ViewModel = the model plus metadata for ui like types of colors(System.Color.Red)

This kind of architecture can reduce development time, since things like converters and extra ui services as separate classes is no longer required but all inside the ViewModel.

הוסף תגובה
facebook linkedin twitter email

Leave a Reply

Your email address will not be published. Required fields are marked *