MVC MVP and MVVM

MVC

Model-view-controller (model-view-controller) is a typical three-layer software architecture. In this layered design, software display interface is separated from logic, which can greatly improve the readability and maintainability of code.

• M: Model, responsible for data processing, including the acquisition and processing of network data and persistent data. In Android, the typical implementation is generally the definition class of data structure;
• V: View, responsible for interface drawing, data display and user interaction, etc. Typical implementation in Android is generally activity and fragment, etc.
• C: Controler, the controller that handles the service logic.

In the standard MVC architecture, both Controller and View depend on the Model. MVC architecture updates data through Controller and presents data through View.

According to the passivity and initiative of Model layer, MVC can be divided into passive mode and active mode. In passive mode, the Model does not actively notify the View of changes that need to be updated. Instead, the Controller notifies the View of changes that need to be updated, and only the Controller can update the Model. In active mode, changes to the Model will notify the View of the update. Active mode uses the observer mode, with the View as the observer and the Model as the observed.

The main disadvantage of passive mode compared to active mode is that the View cannot sense changes to the Model and needs to indirectly notify the updates through the Controller. But it’s also an advantage because the Controller has more control over View updates without having to worry about synchronization issues if the Model notifies you of changes.

The core idea of MVC is the separation of the presentation layer, that is, the separation of the domain model from the view model. In MVC, the domain Model is the Model, and the View Model is the whole View and Controller collaboration. Controller is not only responsible for operating Model for business logic processing, but also for interface display processing related to View, including the processing details of View. Therefore, we can say that Controller shoulders excessive responsibility and is only applicable to small app. When applied to large app, There’s a problem with Massive View Controller.

MVP

Model-view-presenter, a three-tier architecture.

• Mode layer: the Model layer, which is responsible for data processing, including the acquisition and processing of network data and persistent data, etc. In Android, the typical implementation of data structure definition class is similar to Model in MVC.
• View layer: The View layer is responsible for interface drawing and displaying Model data to users. It is typically implemented as Activity/Fragment in Android.
• Presenter layer: Presenter layer, an intermediary between models and views. The View layer passes user interaction response events to the Presenter, who processes the data and informs the View to perform operations such as displaying the data.

In MVP mode, the Presenter layer can rely on the View layer and the Model layer to act as a communication bridge. The event passing flow of the View layer is processed by the Presenter layer operation Model for business logic. The Model layer notifies the Presenter layer when the data is processed, and the Presenter layer communicates with the View layer. The Presenter layer is two-way data flow between View and Model, while View and Model have no direct connection. The MVP model is shown below:

The core ideas of MVP, in addition to having the same separation of presentation layers as MVC, are interface oriented programming and DeMotell’s Law.

Interface oriented programming is the extraction of methods from a class into an interface, which is implemented by the implementation class, and through which the caller interacts with the implementation class. Benefits of interface oriented programming:

• Easy to decouple, reducing dependencies between components
• It helps improve module expansibility
• Helps improve code maintainability
• Make the program structure more clear, enhance the code readability

In Android MVP development, a Contract class is often used to establish a protocol association between a View and its Presenter interface. The Contract interface contains the View and Presenter interfaces.

Demotell’s law is actually the design idea of “high cohesion and low coupling”.

The difference between MVP and MVC is the difference between “C” and “P” and the flow of events that each generates.

• In MVP mode, Presenter only informs the View to display, and the View’s display logic is controlled by the View itself, in accordance with DeMotell’s law. In MVC mode, the Controller controls the display logic of View, which does not conform to Demotell’s law.
• MVP is interface oriented programming, Presenter and View communication through the interface; In MVC, the Controller operates directly on the View.
• In MVP mode, there is no communication between the View and Model, whereas in MVC active mode, changes to the Model can be notified directly to the View.
• MVP is more conducive to unit testing, whereas MVC components are more dependent on each other, which is not conducive to unit testing.

MVP issues:

• Presenter overresponsibility: Compared to MVC, the MVP model gives the Presenter control over the implementation details of the View and only takes care of the business logic, but still has too much responsibility.
• Business logic cannot be used: In traditional MVP mode, a View corresponds to a Presenter. In a Presenter, business logic can only be used for one View, and cannot be used for multiple modules. Different modules will repeatedly operate the same business logic, resulting in a lot of redundant code.
• Rapidly expanding number of interfaces: MVP uses interface oriented programming. During business iterations, changes to existing code often need to be accompanied by changes to the interface layer, and new open methods need to be declared in the interface.

MVVM

Model-view-viewModel

• Model layer: The Model layer is responsible for data processing, including the acquisition and processing of network data and persistent data. The typical implementation in Android is generally the definition class of data structure, which is similar to the Model layer in MVCHE MVP.
• View layer: The View layer is responsible for interface drawing and showing Model data to users. The typical implementation in Android is generally Activity/Fragment, etc.
• The ViewModel layer: The ViewModel layer is responsible for handling data operations related to the business logic. It does not depend on the View. In Android, the DataBinding library can be used to implement bidirectional binding between the View layer and the model layer without requiring the ViewModel layer to notify the View layer of data changes.

The MVVM architecture model is shown as follows:

The core ideas of MVVM:

• Further decoupling: Both MVC controllers and MVP presenters have a direct or indirect dependency on the View. Controller/Presenter coordinates the interaction between the View and the Model. While MVP uses interface oriented programming to indirectly decouple the View from the Model, it doesn’t solve the underlying problem and leads to an increase in the number and complexity of interfaces. In MVVM, the ViewModel no longer holds a reference to the View, but updates the View after data changes through a two-way binding mechanism. It no longer cares about when or how the data should be displayed on the View, everything is done by two-way binding mechanism, so MVVM takes the decoupling a step further.
• Data-driven programming based on the Observer pattern: Data-driven programming is one of the programming paradigms, which focuses on changes in data and causes changes in other components from data. It is event-based programming, which is essentially the observer pattern. Data-driven can prevent coupling between data and functionality and improve development efficiency to a certain extent.
• Bidirectional binding: Bidirectional binding is a good form of data-driven expression, that is, through the observer mode, the realization of View changes can be real-time feedback to the data, data changes can also be real-time feedback to the View. Bidirectional binding is on the basis of one-way binding, the View added the event state change monitoring, through monitoring to dynamically modify the data. Only views have bidirectional binding, and non-views generally only have one-way binding. Unidirectional binding has advantages over bidirectional binding in code tracing and event tracing, while bidirectional binding has advantages of good decoupling and high development efficiency.

Problems with MVVM:

• ViewModel is difficult to reuse: Although ViewModel and View do not have a direct dependency, but the ViewModel is for specific View data service, reuse ViewModel will bring more component compatibility problems to other views. Duplicate code occurs when the same business logic exists between different viewModels, which is just as tricky as Presenter reuse.
• High learning costs: Need to understand bidirectional binding mechanisms and observer design patterns
• Debugging difficulty: Due to the bidirectional binding mechanism, it is difficult to quickly locate the problem of View or Data when the interface display is abnormal.

Comparison of Architectural patterns

MVC advantages	MVC shortcomings	The MVVM advantages	The MVVM shortcomings
Controller can operate View directly, which is more flexible	Architectural components are more coupled than MVVM architectures	Once MVVM is mastered, development becomes more efficient	On small projects, this can increase system complexity
MVC is much more focused on debug tracing	The Controller takes on too much responsibility and is more difficult to maintain	Decoupling is better	Not easy to understand
In terms of architectural understanding, MVC is easier to understand			Harder to debug

MVP advantages	MVP shortcomings	The MVVM advantages	The MVVM shortcomings
Interface oriented design, modify more intuitive and clear	Has more interfaces than the MVVM architecture and requires higher interface maintenance costs	You don’t need the ViewModel to interact with the View frequently	Higher learning costs
Better for testing, the UI is separated from the business logic and interacts through interfaces	Presenter needs to handle the interaction with the View, which is highly complex	There are no more interfaces to maintain	Xml-defined code is more difficult to maintain
It costs less to learn		Viewmodels that handle business logic are less complex than Presenters	Harder to debug

Conclusion: There is no best frame, only the most suitable frame.