MVVM is a derivative of MVC, and the key difference is how each layer in these patterns depends on other patterns and how tightly they are bound to each other. MVC simply stands for Model View Controller while MVVM stands for Model View ViewModel. Both are architectural design patterns that are used for separation of ideas. They enable programmers to develop systems that are maintainable, reusable, and testable.
Every software application and websites have different ways in which they can be structured. Therefore architectural design patterns vary from one application to another. Let's take a look at the three most frequently visited websites: Google, Facebook, and YouTube. Google has a very simple user interface on its main page, while both YouTube and Facebook have different components on their main pages hence making their more complex. You should have noticed that on Facebook and YouTube, components are displayed independently. When you visit the home pages of any of these two websites, a dozen of data requests are made to fill up the page with different components. The components render asynchronously; hence if one part fails, the rest will continue working.
Many other websites have different ways of rendering their information to viewers. But underneath, any website or application has its way in which the front end (View) can reach the right Model to retrieve data. There are two main design patterns, i.e., MVC and MVVM. As you will see in this article, both MVC and MVVM has its own strengths and weaknesses.
MVC vs MVVM
MVC separates the application into three components, i.e., Model, View, and Controller. The View sits on top of the architecture with the Controller beside it, and Models sit below the Controller. Therefore Views know about the Controllers and Controllers know about the Models. Through this method, Views have direct access to Models hence exposing the complete Model to the View. However, this may have security and performance costs, depending on the complexity of our application. MVVM attempts to avoid these issues. MVVM allows us to create subsets of a Model that are View-specific and can hold state and logic information — hence avoiding the need to expose the whole Model to the View. The View can bind to properties on the ViewModel, which exposes the data contained IN Models to the View. This may have performance costs due to a level of interpretation that is required between the ViewModel and the View.
Now let’s look at the individual design pattern
MVC: Model View Controller
This is the most popular and used architectural design pattern. In the MVC design pattern, the Controller acts as the interface that connects and directly manipulates the data in its Model.
Nowadays, applications’ frontend and backend are made to be entirely decoupled from each other. Application user interfaces have become too complex for the view component to be stored in the same file as its data models. The frontend and backend are connected only via get & post requests and JSON strings that are organized through controllers and routers.
The View sends fetch-requests that go to particular routes on the API that are tied to controller actions. The controllers are designed to receive and send appropriate information based on the data received.
MVC design pattern was designed in a way that views and models don't need to know anything about each other. Data between them flows through controllers. This feature allows software developers to work on different parts of an application at the same time without affecting one another. One team can work on the frontend, i.e., the views, and the other can work on the backend i.e., the Model.
Drawbacks of MVC Pattern
The use of controllers to manipulate data models creates clutter in the backend. Every Model in the database calls for its own Controller; therefore, when the application gets much more massive and evolves into an operation with many related models, the number of controllers used must grow so big. This creates a codebase that is difficult to navigate through. Many frameworks have tried to bring in new layers of abstraction, but still, the solution is not of substance.
Some of the blunders in the MVC design pattern are taken care of through the use of ViewModels.
MVVM: Model View ViewModel
MVVM is a derivative of MVC. Also, MVP (Model View Presenter) is MVC's derivative. Both are efforts to deal with issues encountered in MVC. Let's now discuss MVVM as we are talking about MVC vs. MVC in this article.
ViewModel is another popular way to connect a view to a model. MVC is not ideal for every application. Specifically, the controller method doesn't work well with single-page applications. Unlike the controller method, the ViewModel method relies heavily on the frontend of the application.
ViewModel isn't a controller. It acts as a binder that binds data between the View and the Model. While MVC is specifically designed to separate concerns between Model and View, MVVM is designed to allow the View and the Model to communicate directly with each other. For this reason, single-page applications work very well with ViewModels. It will enable the View to communicate directly with models, and it's simple. Google Docs is a perfect example of a single page application. MVVM single-page applications can move quickly and fluidly and save information to the database continuously.
Drawbacks of MVVM
Everything that has an advantage has a disadvantage, and MVVM is no exception. It comes with performance costs. Because it relies on data binding, the ViewModel consumes a considerable amount of memory in comparison to its controlling counterparts. For this reason, MVVM is suited mostly for single-page applications. Larger applications that use the ViewModel method become incredibly challenging to run. The creator of the MVVM pattern himself, John Gossman, said that the overhead for implementing MVVM is “overkill” for simple UI operations (Gossman).
Recently, we have seen the efficiency of programming languages, computing power increase tremendously, and hence the size of applications. This has led to new ways in which programmers organize their codebases and new ways in which applications connect to the data they need.
There are numerous ways in which an application can be structured. In this post, we only discussed two, MCV vs MVVM. Large applications call for MVC design pattern while single-page applications call for MVVM design patterns. So we can assume Facebook and YouTube adopt MVC pattern while many single-page applications created by Google adopt MVVM.
Well, we’ve finally reached the end of MVC vs MVVM. The next time you open an application or a website, I would like you to think about how it was made. Applause for you being so patient and curious! Please share the article with your friends and fellow JavaFX developers!