Why to choose MVVM over MVP
Here we’re gonna talk a littile about Sofware Architecture Patterns and discuss the advantages of MVVM architecture pattern over MVP in the Android app development .
First off why we use such solutions, that some times make it harder and more verbose to write code !?
so there were always problems in development like, changing in one part requires changing a lot of other parts of code or sometimes it’s hard to test some part of code, or making it easier to work with multiple sources of data for example network services or databases.
So software engineers come up with those challenges using Architectural Patterns.
The first widely used Architecture was MVC , MODEL-VIEW-CONTROLLER that does well the separation of concerns, separating view , data layers in a good manner. but there is some hardships testing such software while test-oriented development is gaining momentum in the industry.
+---+ +----| V |<----+ user | +---+ | updates input | | v | +---+ +---+ | C |--------->| M | +---+ updates +---+
Then MVP come up, MVP makes a better separation of concerns over mvc, and delivers a better testability.
This has the following advantages:
- Logic (like event handlers and user interface state) can be moved from the view to the presenter.
- The user interface can be unit tested in terms of the presenter, since it describes the user interface state. Inside the unit test, we replace the view with a test driver that makes calls to the presenter.
- Since the user interface is isolated from the application logic, both can be developed independently
But remains some drawbacks here :
- It requires more effort.
- The presenter can easily mutate into an unmaintainable “god class”.
- The application doesn’t have a single MVP axis, but multiple axes: one for each screen/window/panel in the user interface. This may either simplify your architecture or horribly overcomplicate it.
user input updates +---+ -----------> +---+ --------> +---+ | V | | P | | M | +---+ <----------- +---+ <-------- +---+ updates updates
Then comes the solution, MVVM:
Let’s first take a look at it and describe parts here:
The model is what I like to refer to as the domain object. The model represents the actual data and/or information we are dealing with. An example of a model might be a contact (containing name, phone number, address, etc) or the characteristics of a live streaming publishing point.
The key to remember with the model is that it holds the information, but not behaviors or services that manipulate the information. It is not responsible for formatting text to look pretty on the screen, or fetching a list of items from a remote server (in fact, in that list, each item would most likely be a model of its own). Business logic is typically kept separate from the model, and encapsulated in other classes that act on the model. This is not always true: for example, some models may contain validation.
It is often a challenge to keep a model completely “clean.” By this I mean a true representation of “the real world.” For example, a contact record may contain a last modified date and the identity of the modifying user (auditing information), and a unique identifier (database or persistence information). The modified date has no real meaning for a contact in the real world but is a function of how the model is used, tracked, and persisted in the system.
The view is what most of us are familiar with and the only thing the end user really interacts with. It is the presentation of the data. The view takes certain liberties to make this data more presentable. For example, a date might be stored on the model as number of seconds since midnight on January 1, 1970 (Unix Time). To the end user, however, it is presented with the month name, date, and year in their local time zone. A view can also have behaviors associated with it, such as accepting user input. The view manages input (key presses, mouse movements, touch gestures, etc) which ultimately manipulates properties of the model.
In MVVM, the view is active. As opposed to a passive view which has no knowledge of the model and is completely manipulated by a controller/presenter, the view in MVVM contains behaviors, events, and data-bindings that ultimately require knowledge of the underlying model and viewmodel. While these events and behaviors might be mapped to properties, method calls, and commands, the view is still responsible for handling it’s own events and does not turn this completely over to the viewmodel.
One thing to remember about the view is that it is not responsible for maintaining its state. Instead, it will synchronize this with the viewmodel.
The ViewModel (Our Controller/Presenter)
The viewmodel is a key piece of the triad because it introduces Presentation Separation, or the concept of keeping the nuances of the view separate from the model. Instead of making the model aware of the user’s view of a date, so that it converts the date to the display format, the model simply holds the data, the view simply holds the formatted date, and the controller acts as the liaison between the two. The controller might take input from the view and place it on the model, or it might interact with a service to retrieve the model, then translate properties and place it on the view.
The viewmodel also exposes methods, commands, and other points that help maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself.
MVVM, while it evolved “behind the scenes” for quite some time, was introduced to the public in 2005 via Microsoft’s John Gossman blog post about Avalon (the code name for Windows Presentation Foundation, or WPF). The blog post is entitled, Introduction to Model/View/ViewModel pattern for building WPF Apps and generated quite a stir judging from the comments as people wrapped their brains around it.
I’ve heard MVVM described as an implementation of Presentation Model designed specifically for WPF (and later, Silverlight).
That’s a brief description of MVVM , so what’s advantages it has over MVP:
MVP has some drawbacks that could bring us some hard times , like :
For each Activity/Fragment (View) we require a Presenter. This is a hard bound rule. Presenter holds the reference to the Activity and Activity Holds the reference to presenter. 1:1 relationship and thats where the biggest issue lies.
As the complexity of view increases, so does the maintenance and handling of this relationship.
This eventually lead to same issue we faced earlier as in for quick changes in design, we actually need to modify the whole relationship.
Picking a statement from our end goal “Build things in a distributed manner”, In order to achieve it and to avoid this tight relationship ViewModels were introduced.
ViewModels are simples classes that interacts with the logic/model layer and just exposes states/data and actually has no idea by whom or how that data will be consumed. Only View(Activity) holds the reference to ViewModel and not vice versa, this solves our tight coupling issue. A single view can hold reference to multiple ViewModels.
Since Presenters are hard bound to Views, writing unit test becomes slightly difficult as there is a dependency of a View.
ViewModels are even more Unit Test friendly as they just expose the state and hence can be independently tested without requiring the need for testing how data will be consumed, In short there is no dependency of the View.
Now that’s the time for MVVM :
The key difference between the Model View Presenter model and the Model View ViewModel lies in the way they update the view. The MVVM uses databinding to update the view whereas the presenter uses traditional methods to update the view.
The most important thing that MVVM claims to solve is the testability of code due to separating of View more from ModelView comparing MVP as ModelView has no reference to the view so it’s a level up in the test driven development . and in testing View and ModelView/Model layers are different processes and tasks . so no mocking requires for testing ViewModel Layer .
Hope You enjoy .