Previously I post an artical to talk about the MVC design pattern. In here, I will continue our discussion and dig deeper in what exactly the MVC is. Also, a comparison between MVC and the MVVM (Model-View-ViewModel) pattern will be conducted.
MVC and MVVM
If you are a developer working on web application developing, the word MVC should be not a stranger for you. Generally the MVC stands for Model, View and Controller. it has an extension, or a brother called MVVM, who stands for Model, View and ViewModel. Before we talk about more deeper about it, I would like to start here by introducing some key differences between them.
In MVC, controller knows about the VIEW, and change the VIEWs. Controller also knows the Model and Call the model in neccessary. In theorically, the archetect of MVC should looks like down:
Yes the diagram above looks a little bit unusual. Noramlly the View would directly connect to Model and the “User” word would replace the “Client”. However, I chose this picture is because it is more real. View would take the data wrapped based on Model and provided by Controller. Controller take the data modeled by Model from database via an well built ORM framework. In MVC, the data flow is single binded. Actually the Client could send data directly to client side and skip the VIEW layer. We will talk about it later.
Ok, so hows about the MVVM. In MVVM, the ViewModel is an abstract representation of the VIEW and Doesn’t know about concrete UI. VM wrap the Model and display it in way desired. So is it ok to think the VM is more powerful than Controller in MVC? Well it is an tricky thing beacuse sometimes they are quite mixed up.
Take a step further
We still focus on the Controller and ViewModel.
In MVC, controller is the logic centre and it knows how VIEW interact with MODEL. VIEW actually could directly present the MODEL because the user interface sometime only need to present the original data. in this scenario, the middleware, aka. controller, is called “ReadOnlyController”.
In MVVM, that kind of scenario seems be unsusal. VM controls the way the data present and VIEW only present it.
Thus, In MVC CONTORLLER’s workload depends on the demand, sometime it won’t be involved in the circle. But in MVVM the VM is desided to decide which way the data should be presented.
Why do MVVM?
Main purpose for ViewModel in MVVM is try to make the VIEW logic separate from UI. VIEW layer only present all the thing VM provide, and the UI is more like the frame ow the window user could take a view of the data content.
the VM has no idea what VIEW is displaying neith ther where the data is coming from, which has been mentioned above. That approach is especially reusable in practice beacuse most of the logics are not stored in controllers. (Yes, In MVVM controller is still exist.) VM in most of the time is playing a bridge between designer of VIEWs and Coders. Sot eh VM should be kept simple. Theoretically in MVVM, Controller will contain some precessing logic of data and decide which VM should be display in application ONLY. Therefore, from what we have sson so far, the main benefit of MVVM is that it removes code from VIEW, most of the time are the XAMLs, to make Front-End independently and easy for unit tests. Along with that, we still need to create CONTROLLER for overall logic in application.
The desciprition above actually introduce an pattern widely used in practices, the M.V.C.VM
M.V.C.VM
Taking the Controller in MVVM as the same level with others could provides us several benefits:
- VIEWs display a certain shape of data, which is selected by CONTROLLERs, and it has no idea where the data comes from.
- VM holds a certain shap of data and commands, but no idea where the data and code come from and how to display it.
- Models still hold the actual data (forms).
- controller listen for events and publish them.
- Only the controller objects need to exist in memory for the life of the application*.
- Controller contains mainly code and little state data, which makes for much less memory-intensive apps than solutions where VM have to be retained and it is ideal for certain types of mobile apps.
So, in summary, the MVCVM sometimes is just the practise mode of MVVM. And all modifications are just for making the application testable.
Back to MVC
Not matter you using MVVM or MVC, over weight of controller is a problem you should facing to. Here I will make an example for how to reducing the size of controller.
In MVC, View and Model are quite fitting the iead of “reducing repeating” jobs. i.e., iPad and iPhone applications could use same data Model and the same Views. Controller should be the place stores the no-reusable codes. Fortunately, in the no-reusable code, extacting the repeating jobs is still possible.
Assuming here is a scenario with a server providing data via API and an application consuming the API. Mainly job of the server side’s controller is handling various request and get data via ORM framework. We can extract the HTTP request handling function and response function into a service outside controller. Controller is only acting like a data flow HUB.
Another example of weight losing is that we take advantages of MVVM and construct VM for defining data fomat we want to present in Views, and controller only passing VM to Views.
What Next?
In the next step, I will make an example of the new MVC example on ASP.NET Core and present how to build an sample MVC app in Visual Studio.
Adventure of an Starter 