MVC Pattern

Model-View-Controller — separating UI concerns from business logic

1. Overview: MVC, a pattern that splits UI, logic, and data into three roles for independent development

    flowchart LR
    A["UI, business logic, and data<br/>mixed into one codebase —<br/>changes affect everything"] --"Separate roles into<br/>Model, View, Controller"--> B["Separation of concerns,<br/>independent development and testing"] --"Replace the UI,<br/>reuse business logic"--> C["Improved maintainability<br/>and reusability"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: A software architecture pattern that splits an application into three roles — Model (data and business logic), View (user interface), and Controller (request handling and flow control) — so each component can be developed, changed, and tested independently.

Characteristics: (General-purpose UI pattern) Originated in Smalltalk in the 1970s and is applied broadly across web, mobile, and desktop applications as a general-purpose UI pattern. (Adopted by major frameworks) The foundational design pattern behind major web frameworks such as Spring MVC, Django, Rails, and ASP.NET. (Observer pattern) View and Model can communicate directly, with the View observing Model changes (Observer pattern).

2. Core Structure of the MVC Pattern

A. Separating the Model, View, and Controller Roles

    flowchart TD
    USER["User"]

    subgraph MVC["MVC Components"]
        direction TB
        CTR["Controller<br/>receives requests, controls flow,<br/>calls Model, selects View"]
        MOD["Model<br/>business logic and data,<br/>state management, DB integration"]
        VIW["View<br/>user interface,<br/>renders Model data"]
    end

    USER -->|"Request"| CTR
    CTR -->|"business processing request"| MOD
    MOD -->|"returns data/state"| CTR
    CTR -->|"rendering instruction"| VIW
    MOD -->|"state-change notification<br/>(Observer)"| VIW
    VIW -->|"Response"| USER

    style CTR fill:#E3F2FD,stroke:#1976D2,color:#000
    style MOD fill:#1E3A5F,stroke:#1E3A5F,color:#fff
    style VIW fill:#E8F5E9,stroke:#388E3C,color:#000

Component	Key Responsibility	Included Elements	Change Triggers
Model	Applies business rules, manages data state, integrates with the DB	Entity, Repository, Service, DTO	Changes in business rules or data structure
View	Visually presents data to the user	HTML Template, JSP, Thymeleaf, React	Changes in UI design or screen layout
Controller	Receives requests, validates parameters, calls Model, selects View	`@Controller`, `@RestController`	Changes in request flow or routing

MVC Request Processing Flow (Spring MVC Example)

Step	Handler	Description
1	DispatcherServlet	Entry point for all HTTP requests (Front Controller)
2	HandlerMapping	Finds the Controller method matching the URL pattern
3	Controller	Calls business logic, returns a ModelAndView
4	ViewResolver	Resolves the logical view name to an actual View (Template)
5	View	Renders Model data as HTML/JSON and responds

B. MVC Variant Patterns (MVP, MVVM)

    flowchart TD
    subgraph R1["　"]
        direction LR
        MVC2["MVC<br/>Model-View-Controller<br/>Controller coordinates View and Model<br/>View can reference Model directly<br/>Spring MVC / Django / Rails"]
        MVP["MVP<br/>Model-View-Presenter<br/>Presenter fully mediates View and Model<br/>View only references the Presenter<br/>Android (classic) / WinForms"]
    end
    subgraph R2["　"]
        direction LR
        MVVM["MVVM<br/>Model-View-ViewModel<br/>ViewModel manages View state<br/>auto-sync via data binding<br/>Vue / React / Angular / WPF"]
        FLUX["Flux / Redux<br/>unidirectional data flow<br/>Action → Dispatcher → Store → View<br/>state management in the React ecosystem"]
    end

    style MVC2 fill:#E3F2FD,stroke:#1976D2,color:#000
    style MVP  fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style MVVM fill:#FFF3E0,stroke:#F57C00,color:#000
    style FLUX fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

MVC vs. MVP vs. MVVM

Comparison	MVC	MVP	MVVM
Mediator	Controller	Presenter	ViewModel
View–Model relationship	View can reference Model directly	Presenter fully mediates	Auto-synced via data binding
Testability	Controller unit tests are straightforward	Presenter unit tests are straightforward	ViewModel unit tests are straightforward
View independence	Moderate	High (View is only an interface)	High (decoupled via binding)
Suitable environment	Server-side rendered web	Android, desktop apps	Client-side SPA, WPF
Representative frameworks	Spring MVC, Django, Rails	Android MVP, WinForms	Vue, Angular, WPF, Kotlin

3. Expected Benefits and Application of the MVC Pattern

Category	Key Expected Benefit	Application and Practical Use
Separation of concerns	UI changes don’t affect business logic	Parallel development by designers (View), backend engineers (Model), and full-stack engineers (Controller)
Testability	Model can be unit-tested independently of the UI	Unit-test Service/Repository with JUnit, using mock Views
Reusability	The same Model serves Web, API, and mobile views	Reuse the Model for REST API design, swapping only the View
Maintainability	Screen changes touch only the View; logic changes touch only the Model	Gradual migration by replacing the View when modernizing legacy UI

Layered Architecture Hexagonal Architecture