I know how to works MVP architecture but I'm a little confused with the logic of MVVM architecture.
For further actions, you may consider blocking this person and/or reporting abuse
I know how to works MVP architecture but I'm a little confused with the logic of MVVM architecture.
For further actions, you may consider blocking this person and/or reporting abuse
Chris Jarvis -
Oliver Bennet -
Alexander Shagov -
Jess Lee -
Top comments (7)
You are 5y and trying to learn basic algebra.
You mother makes you a cool software in which you can learn in an interactive way.
Math is a big field, the software your mother made is made out of 2 sides:
All the state of the front end, how many exercises you did since you started the cool software, what results you wrote and how many apple to draw on the screen are kept in a cool front end software box called the ViewModel.
While the mathematical model is in charge to replicate the business logic, in this case the basic algebra operators and functions, the ViewModel is in charge of storing user interface stuff like
You can appreciate your mother using this pattern, otherwise it will had to pollute the mathematical model with lesser things like apples.
mathematical model - MVVM, model, the business logic of your app
ViewModel - it stores data needed for the UI AND transforms the data from the Model to be represented on the screen in a friendly way.
The model decides what exercise you should do next and corrects the results, the information is sent to the ViewModel, the VM translates the information from ugly (number 5) math to beautiful apple's icons (5 apples).
Some info is kept in both Models, but for different purposes:
Each Model can have special data that is not shared with the other one, for example the VM can have the Display resolution which is needed to calculate how big the apples should be on the screen, the Model doesn't care about this.
There are some environments where the VM is the principal actor in the app, you can learn and have fun making mini games in Unity3D, where you have components attached to objects, they are usually ViewModels where you keep data and logic for the UI, size of the text, shaders etc.
This story was inspired from a real story, my father made me a multiplication Basic software in which I learned math, it was way cooler than boring exercises from school on paper.
I haven't explained the Controller or Model parts, because they are same in both patterns.
If you are not using the ViewModel pattern most likely its logic and data is scattered around, usually in the View.
I made a graph, for the data (not event flow) differences, as another example.
Nice explanation!
Although this may not be true, one to think about it is:
Using a "ViewModel" or sometimes called selectors is a mildly common pattern in Redux and Elm. Although it's only needed for very complex interfaces and often used in conjunction with other patterns.
I'm no expect, take this with a grain of salt.
I have worked with many self-identified MVVM libs or frameworks and I still can't really explain it. I feel like it's more of a marketing term than a legit differentiation from MVC.
Or the differences are so minimal or abstract that I just really don't care to remember.
Edit: Actually, I guess now that I think of it I can see that MVC/MVVM is different in terms of domains. You can have a MVC web server and a MVVM front end, I guess!
But now we're already out of the domain of five year olds so...
It is a big difference, VM is the model of the view, it's in charge of all the data required by the View to do it's functions.
I think MVVM is what the originally MVC was, 40yrs ago, but now MVC means something else, the Model has business logic & business data, the ViewModel has View logic & data.
Not for a 5 year old, but could help the developers seeking truth. :-)
Take a React app for example.
In MVC, React component is View. It takes some raw model and figures out how to show it the best way. Probably, it also asks some services, does some API calls to do it. Usually you end up mocking the dependencies to test it, using virtual DOM, imitating user interactions like clicks. And you really want to test it, since there are all sorts of things that can go wrong due to integrations.
In MVVM, React component is as dumb as it can get. No integrations, no calculations. It just receives a ViewModel as Props and renders it. To make it possible, ViewModel should supply all the necessary data. Like apple image locations, boolean conditions whether to show some part of the view or not. In this case you test the code that produces the ViewModel. You do not need virtual DOM or user interactions in these tests, so you can focus on service integrations and business logic.