Catalog
concept#Architecture#Software Engineering#Integration#Product

Model-View-Presenter (MVP)

A UI architectural pattern separating presentation, presentation logic and the data model.

Model-View-Presenter (MVP) is a UI architectural pattern separating presentation, logic, and data.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Unit test frameworks (e.g. JUnit, NUnit)Mocking libraries (e.g. Mockito)UI frameworks (e.g. WinForms, Android SDK, WPF)

Principles & goals

Clear separation of presentation and logicPresenter as the sole layer containing UI logicViews remain passive and know no business logic
Build
Team, Domain

Use cases & scenarios

Compromises

  • Presenter may become a complex business logic God object
  • Improper interface definitions increase coupling
  • Lack of discipline leads to mixed responsibilities
  • Keep views as passive as possible; logic in the presenter.
  • Write presenter unit tests before UI integration.
  • Avoid business logic in the presenter; delegate to the domain layer.

I/O & resources

  • UI specifications and user requirements
  • Existing domain model / backend APIs
  • Test infrastructure (unit tests, mocks)
  • Separated presenter, view and model components
  • Automated tests for presenters
  • Defined interfaces and adapters

Description

Model-View-Presenter (MVP) is a UI architectural pattern separating presentation, logic, and data. The Presenter mediates between Model and View, improving testability and clearly separating responsibilities. MVP is suitable for complex user interfaces requiring reusable presentation logic, modular structure and reduced coupling.

✔

  • Improved testability via isolated presenters
  • Clear responsibility boundaries between UI and domain
  • Reusable presentation logic across platforms

✖

  • Can produce boilerplate through many interfaces
  • Overuse can lead to too many presenter classes
  • Not always optimal for simple, purely declarative UIs

  • Presenter test coverage

    Percentage of presenter functions covered by automated tests.

  • Number of presenters per view

    Measures modularity and granularity of the presentation layer.

  • Time-to-change for UI (lead time)

    Time required to implement and test a UI change.

Desktop application with clear presenter tests

A finance desktop application uses presenters to encapsulate complex input logic and enable automated tests.

Android app using the Mosby framework

An Android app implements MVP using the Mosby library to reuse presenter logic.

Refactoring a WinForms UI

Legacy WinForms code was gradually moved into presenters, improving testability.

1

Identify views and extract UI logic into presenters.

2

Define clear interfaces between view and presenter.

3

Implement presenters with unit tests and use mocks for views/model.

4

Integrate presenters gradually into existing views and refactor iteratively.

⚠️ Technical debt & bottlenecks

  • Unrefactored presenters with mixed logic
  • Outdated adapters between presenter and model
  • Missing test coverage in critical presenter paths
Presenter complexityInterface overheadTest coverage effort
  • Moving full domain logic into presenter instead of domain layer.
  • Introducing MVP for very simple form views without benefit.
  • Creating many fine-grained presenters with redundant responsibilities.
  • Presenter becomes change bottleneck if too much responsibility is centralized.
  • Unclear interface contracts lead to repeated refactoring.
  • Missing tests allow creeping mixing of responsibilities.
Knowledge of architectural patterns (MVP/MVC)Ability to define and mock interfacesExperience with unit testing and TDD
Testability of presentation logicCross-platform reusabilityLow coupling between UI and domain
  • • Platform API may force passive views
  • • UI framework constraints can influence presenter design
  • • Team experience with pattern and test automation required