Free lesson · Low Level Design Fundamentals

MVC

Medium4 min readlldoopdesign-patterns

MVC Pattern

Model-View-Controller (MVC) is an architectural pattern that separates an application into three distinct parts: the Model (the data and business logic), the View (the presentation/UI), and the Controller (which handles input and coordinates the other two). The intent is to keep the what the application knows and does (Model) cleanly separated from how it's displayed (View) and how user input is handled (Controller), so each can change independently - you can redesign the UI without touching business rules, or add a new interface (web, mobile, API) reusing the same Model.

This topic is part of the Additional Patterns module, and it's the most prominent application of Separation of Concerns (Module 7.5) to interactive applications. It builds on several earlier ideas: the Model/View split is SoC and layering; the classic View-observes-Model mechanism is the Observer pattern (Module 17.2); and the Controller coordinating without owning business logic echoes the Service Layer (Module 20.2). MVC and its descendants (MVP, MVVM) are the backbone of essentially every UI framework.

In interviews, MVC comes up in any UI-flavored design and as a touchstone for SoC. The signal is understanding the responsibilities and dependencies of each part - especially the rule that the Model knows nothing about the View - rather than just naming the three letters.

The Problem It Solves

Without MVC, presentation, input handling, and business logic tangle into unmaintainable screens:

class UserProfileScreen {
    void onSaveButtonClicked() {
        String name = nameTextField.getText();              // UI access
        if (name.isEmpty()) { showError("name required"); return; }  // validation in UI
        db.execute("UPDATE users SET name=? ...", name);    // persistence in UI
        nameLabel.setText(name);                            // UI update
        sendAnalytics("profile_updated");                   // business concern in UI
    }
}

The screen class handles UI, validation, persistence, and business concerns all at once - so the business logic can't be reused on another screen or tested without the UI, and changing the layout risks breaking the rules. MVC splits these: the Controller receives the click, the Model holds the user data and the save/validation logic, and the View just renders. Each can be changed and tested in isolation.

The Three Parts and Their Dependencies

graph TD
    U[User] -->|interacts with| V[View<br/>renders Model, sends input events]
    V -->|input events| C[Controller<br/>handles input, updates Model]
    C -->|updates| M[Model<br/>data + business logic]
    M -->|notifies of changes| V
    M -.knows NOTHING about.-> V

    style M fill:#1e1b4b,color:#fff

A diagram of Model-View-Controller and its dependencies. The user interacts with the View, which renders the Model and forwards input events. The Controller handles those input events and updates the Model, which holds the data and business logic. When the Model changes, it notifies the View to re-render - typically via the Observer pattern. The critical rule, shown as a dashed line, is that the Model knows nothing about the View: the dependency points from View to Model, never the reverse. This one-directional knowledge is what lets the UI change freely without touching business logic, and lets multiple views share one model.

Model - the heart of the application: domain data and business logic. Crucially, it knows nothing about the View or Controller; it can run headless and be tested without any UI. When it changes, it notifies observers (the View) without referencing them concretely.
View - renders the Model's state and captures user input. It contains no business logic - it's a projection of the Model.
Controller - translates user input into operations on the Model, and selects which View to show. It coordinates; it doesn't contain the business rules (those live in the Model).

The dependency rule is the essence: knowledge flows View → Controller → Model, and the Model depends on neither. That one-way dependency is what makes the parts independently changeable.

MVC and Its Variants

MVC has well-known descendants that adjust the View-Controller relationship: MVP (Model-View-Presenter) routes everything through a Presenter that updates a passive View; MVVM (Model-View-ViewModel) uses data binding so the View syncs to a ViewModel automatically. They share MVC's core SoC; they differ in how input and view-updates are wired. The common thread - and the interview-relevant point - is the strict separation of business logic (Model) from presentation (View), with a coordinator in between. Modern frameworks (web MVC, iOS/Android architectures, frontend component models) are all variations on this theme. Don't over-engineer a tiny app into rigid MVC, but for anything with non-trivial UI and logic, the separation pays off.

Why This Matters in Interviews

For any design with a user interface, MVC (or a variant) is the expected structuring answer, and it's a concrete way to demonstrate Separation of Concerns. The depth signals: stating that the Model knows nothing about the View (one-way dependency), that business logic lives in the Model rather than the Controller or View, and that the Model-notifies-View mechanism is the Observer pattern. Recognizing MVP/MVVM as variants on the same SoC theme shows breadth without losing the core principle.

Common Mistakes

Fat controllers. Putting business logic in the Controller instead of the Model, recreating the tangle MVC exists to prevent.
Model depending on View. Letting the Model reference the UI breaks the one-way dependency and the reusability it enables.
Logic in the View. Validation and rules in the UI layer, so they can't be tested or reused headlessly.
Anemic model, smart view. Treating the Model as a dumb data bag while the View/Controller hold the behavior (an anemic-domain smell, Module 24).
Over-applying to trivial apps. Forcing full MVC ceremony onto something with no real logic or multiple views.

Try It

Take a UI screen (or endpoint handler) that mixes rendering, input handling, and business logic, and split it into the three roles: move the data and rules into a Model that has no reference to the UI, leave the View to render and capture input, and let a Controller wire input to Model operations. Then test the payoff: can you exercise the Model's logic with no UI at all, and could you add a second View (say, an API alongside the web page) reusing that Model unchanged? If yes, you've achieved the separation MVC is really about.

Back to Low Level Design Fundamentals