MVVM vs MVC
Updated: May 13, 2020
Do we really have to keep trying to reinvent the wheel?
About this post I really think that MVVM is a valid approach, however, I want to point out one significant drawback, and show you how I approach code Architecture in my Android projects. Google Advocates for MVVM Code Architecture is not a new concept - it's been around for decades. It has already gone through multiple natural selection cycles. MVVM was first introduced in 2005 by John Gussman In May 2018, Google introduced the JetPack Architecture Components and made MVVM its Recommended App Architecture
MVVM (Model View View-Model) uses ViewModel and LiveData In MVVM The Activity/Fragment uses the ViewModel to binds itself to LiveData and observes for data changes and reflects the changes in the UI. This approach addresses one of the major pains in Android development passing data between Components and keeping your UI updated. MVVM advocates for "Single point of truth" and the Repository is a singleton and no matter who add/remove/update data he will use the same Repository instance - and by changing the data all the components that observe it will get updated automatically. There is an excellent tutorial by Matt Rešetár, I recommend starting there. MVVM implementation Github example
MVC Architecture MVC (Model-View-Controller) goes a long way back to the late 70's and has many interpretations. Here I'm going to show how I implement MVC in my Android projects:
Model - I use Clean Architecture Approach so the Modle is the Domain layer. View - an Implementation of an Interface that holds only UI Logic, it notify user interaction using an Observable. Controller - Activity/Fragment/Adapter/Dialogs - it uses the Interactors from Domain layer to fetch data and using the ViewMvc Interface to control the View and receive user interactions via the Observable.
A few sentences about Clean Architecture approach Presentation - UI related functionality only. Here I implement a classic MVC - where the Activity is the Controller - it requests data from the Domain which function as the model and then it present the data to the user via the View - which holds no logic - whatsoever. The View passes user interactions to its Controller using callbacks. Domain - this is where all the core business logic goes. It doesn't aware who is asking the data and it is not aware of where the data came from. this is thanks to the 'D' in Solid - Dependency inversion. This isolation is the real benefit of Clean Architecture. This layer should be written in a pure programming language - it should not use any framework whatsoever - and it should also be 100% covered by Unitests. Data - This is where we fetch data from cache/Preferences/Files/locale DB or the backend, This layer is unaware who is asking data from it - it simply returns the data. Dependency Injection - This is a very important part of my code architecture, if you don't use dependency injections I recommend you look into Vasiliy Zukanov course Here is a link to my code sample on Github So MVVM or MVC? MVVM for Android is powerful, it really makes it easier to keep your UI up to date. It also respects the Separation of concern principle, and all and all it is a good and valid approach, but. and there is a but, I believe that there is a dangerous Tradeoff. Robert Martin Clean Architecture discipline is gaining popularity. and it's not a coincidence. The most basic idea he is trying to convey to the developers community is that coupling your code architecture with Frameworks should be avoided at all cost. I invite you to read Robert Martin's Screaming Architecture Article Clean Architecture has 3 layers: 1. Presentation 2. Domain 3. Data The Presentation and Data Layers using the Framework, they have to - but the Domain, where all the business logic resided, is completely detached. and Written in pure, low level, programming language. Besides following the SOLID principles, you gain another powerful benefit. writing Unitets for the domain layer become very easy and efficient, which has tremendous value. MVVM binds you to Android Framework Once you have implemented MVVM and your project grows you are stuck with it - ViewModel and LiveData become part of your project forever because it's rooted in the very heart of your architecture. Moreover using LiveData makes writing Unitests more difficult. Another problem is that LiveData and ViewModel are new components, any developer experienced as he may be, if he is not familiar with these relatively new concepts and when he will try to get into your code it will force him to learn these concepts, while if you use MVC it will be much easier for him to understand. There is an excellent talk by Vasiliy Zukanov about it To Conclude
From my own experience, MVC with a clean architecture approach gives you much more flexibility and for me, it is my preferred Architecture. However, there is no black and white here, I totally respect developers that use MVVM and maybe they have more insights about its benefits. I would really love to hear your thoughts - and have a productive discussion - so please feel free to leave your comments.