Understanding MVC, MVP, and MVVM: Concepts, Differences, and When to Use Them

All MV* series involve a Model and a View, but without a coordinating component they cannot work together, which leads to various MV* design patterns.

MVXX patterns:

MVC

MVP

MVVM

These three architectures are popular today; different projects may adopt different patterns. The following sections introduce their concepts, usage scenarios, and differences.

MVC

MVC (Model-View-Controller): Model is the logical data layer, View is the UI layer, and Controller handles user input. The goal is to separate business logic, data, and interface, allowing changes to the UI or interaction without rewriting business logic. Both Controller and View depend on the Model, while Controller and View also depend on each other.

Operation flow: The user interacts with the UI (e.g., a mobile screen); the View captures the interaction and passes control to the Controller. The Controller preprocesses the data from the View, decides which Model interface to call, and the Model executes the corresponding logic. After the Model changes, it notifies the View via the Observer pattern; the View then requests the latest data from the Model and updates the page.

Key points to note:

The View hands over control to the Controller, which executes application‑specific logic (pre‑processing View data, deciding which Model interface to invoke, etc.).

The Controller manipulates the Model, which processes business logic and data, but never directly touches the View; it remains unaware of the View.

Synchronization between View and Model occurs via the Observer pattern: the View requests Model data and updates itself.

The essence of MVC lies in point three: Model updates are communicated to the View through the Observer pattern (e.g., Pub/Sub or Events). This enables multiple Views to share a single Model and stay synchronized in real time.

Advantages

Multiple Views can share one Model, greatly improving code reusability.

The three modules are independent; changing one does not affect the others, reducing coupling and allowing developers to focus on a single layer.

The Controller enhances application flexibility and configurability by linking different Models and Views to satisfy user requirements.

Disadvantages

Increases the complexity of system implementation.

The coupling between View and Controller can be too tight; without a Controller, a View has very limited capabilities, making independent reuse difficult.

View access to Model data can be inefficient due to multiple calls.

Views are not easily componentized; they depend on specific Models, making reuse across applications challenging.

MVP

Model‑View‑Presenter: Model is the logical data layer, View is the UI layer, Presenter acts as an interface.

Definition of MVP:

- An evolution of MVC that fully decouples Model and View
- Cleaner code, but introduces many classes

In MVP, the Presenter receives user actions from the View, executes the corresponding logic, and interacts with the Model. After the Model finishes its business logic, it notifies the Presenter (instead of the View) via the Observer pattern. The Presenter then updates the View through its interface.

In Android, the View may be just a layout file, while the Activity performs data binding and acts like both View and Controller.

After applying MVP:

- View: corresponds to Activity, responsible for rendering and user interaction
- Model: business logic and entity models
- Presenter: mediates between View and Model

Illustrative diagrams:

Advantages of MVP

Facilitates testing: Presenter interacts with View via an interface, allowing mock Views for unit testing without UI dependencies.

View can be componentized: Since View does not depend on Model, it can be detached from specific business scenarios and reused across projects.

Disadvantages of MVP

Increases code volume and implementation difficulty.

MVP vs. MVC

See the diagram below for a visual comparison:

MVVM

MVVM stands for Model‑View‑ViewModel. It is a conceptual evolution of MVP that centers on two‑way data binding, allowing automatic synchronization between View and Model without manual glue code.

Interaction Flow

The interaction flow resembles MVP, but a Binder (or data‑binding engine) in the ViewModel handles synchronization. Developers declare in the View template which Model data should be bound to which UI element. When the ViewModel updates the Model, the Binder automatically updates the View; when the user interacts with the View, the Binder updates the Model. This is known as two‑way data binding.

Thus, MVVM automates the synchronization logic that MVP required the Presenter to handle manually, delegating it to the framework’s Binder. Android’s official DataBinding library is an example of this approach.

Advantages

Improves maintainability by eliminating manual View‑Model synchronization and providing a built‑in two‑way binding mechanism.

Simplifies testing: since synchronization is handled by the Binder, ensuring Model correctness automatically keeps the View consistent.

Disadvantages

Overkill for simple graphical interfaces; it can be like using a sledgehammer to crack a nut.

For large applications with many view states, constructing and maintaining ViewModels can become costly.

Binding declarations are written in the template, making them hard to debug with traditional breakpoints.

Related Resources

Brief discussion of MVP in Android

Detailed analysis of the MVC three‑layer framework

Reconstructing real MV* patterns