MVVM (MVC, MVP)

MVVM #

MVVM (Model–View–ViewModel) is a presentation-oriented architectural style commonly used in modern UI applications (including Android). The primary goal is to separate the UI logic (which usually needs to be real-time interactive), UI state, and business logic.

Topology #

Example package/class diagram:

MVVM topology example

  • Components
    • View: renders UI; listens to user events; reacts to UI state changes.
    • ViewModel: holds UI state; redirects user events to business logic; fills data into UI state.
    • Model: business logic, network calls, data access, etc.
  • Connector:
    • control flows from View to ViewModel to Model;
    • data flows backwards.

Pros and cons #

  • Pros
    • Maintainability: UI logic and business logic are easier to maintain separately.
    • Separation of concerns: UI logic and business logic do not mix together; UI elements can have different (usually shorter) lifetimes than the ViewModel and Model classes.
    • Reusability: one ViewModel can be shared by multiple Views when needed.
    • Testability: ViewModel and Model can be easily unit-tested without rendering UI.
  • Cons
    • Overkill for simple state: the extra abstraction may slow down simple projects.
    • Debugging: reactive flows and state propagation can be harder to trace without good tooling.

Variants #

MVC and MVP are older versions of MVVM that aim for similar goals (separation of concerns) but differ in where UI logic/state lives and how tightly the “middle” component is coupled to the view.

MVC (Model–View–Controller) #

In practice, “Controller” often becomes an overloaded component (inputs + state update + business logic) and can become tightly coupled to the View.

MVC topology (simplified)

MVP (Model–View–Presenter) #

Presenter is an explicit adaptor between view and model. A typical distinction from MVVM is that the presenter often holds a reference to the view (via an interface) and pushes updates to it.

MVP topology (simplified)

In MVVM, the ViewModel is typically designed not to depend on the concrete View, so that View and ViewModel can have different lifecycles and the View can be recreated freely.

Real-world examples #

Android apps: ViewModel as state holder (MVVM-style) #

In Android apps, the view is usually an Activity/Fragment/Compose UI, and the viewmodel is a lifecycle-aware state holder. The common connector is a unidirectional flow of state from viewmodel to UI (e.g., StateFlow/LiveData), with user events flowing back as method calls or event streams. This is a practical adaptation of MVVM to Android’s lifecycle constraints (configuration changes, background/foreground transitions).

Further reading:

Android Architecture Samples (includes MVP variants) #

This repo is useful for comparing how connectors change across variants. For example, in an MVP setup, the presenter typically calls view methods through a view interface, while in MVVM the UI usually observes state and reacts to it. Those choices affect lifecycle handling, test strategy, and how UI state is represented.

Further reading: Android Architecture Samples

Rails (MVC in web applications) #

Rails is a well-known example of MVC in the web domain. Controllers handle HTTP requests (connector: request/response), models encapsulate domain/data logic (often via an ORM), and views/templates render HTML. Web frameworks adapt the classic topology with routing, middleware, and conventions to keep controller logic manageable.

Further reading: Rails Guides: Action Controller Overview

Django (MTV: a close cousin of MVC) #

Django describes its architecture as MTV (Model–Template–View). It maps closely to MVC with different naming conventions: the “view” is a request handler (similar to a controller), and the template is the presentation layer. This is a reminder that real ecosystems often rename and bend the classic patterns while keeping the separation-of-concerns idea.

Further reading: Django FAQ: MVC vs MTV naming