Model-View-Controller (MVC): Separating App Logic from UI

Why it exists

MVC was created to impose a high-level architecture on applications, separating their core functions into distinct roles. This separation makes code more reusable, interfaces better defined, and the entire application more adaptable to changing requirements. Without a pattern like MVC, data logic and presentation code become tightly coupled, making the system brittle and hard to maintain.

The mental model

Think of MVC like a restaurant. The Model is the kitchen, holding the ingredients (data) and recipes (business logic). The View is the dining room, presenting the food to the customer and displaying the menu. The Controller is the waitstaff, taking orders from the customer (View), relaying them to the kitchen (Model), and bringing the finished dish back to the table (updating the View).

How it works

The pattern defines three distinct object types with clear boundaries.

Model

This object encapsulates the application's data and the logic to manipulate it. It is the single source of truth. Crucially, the Model has no direct knowledge of the user interface. A Person model might store a birthdate, but not the string format for displaying it.

View

This object is responsible for presenting the Model's data to the user and capturing user input. It should not contain business logic. A View can be a simple button or an entire screen. It observes the Model (usually via the Controller) for changes so it can update its appearance.

Controller

This object acts as the intermediary. It receives user actions from the View, processes them by interacting with the Model, and then updates the View with any new data. It's the glue that connects the other two layers.

When to use it

MVC is the default architectural pattern for many UI frameworks, especially in Apple's ecosystem (Cocoa, UIKit, AppKit). It's a solid choice for applications where there is a clear distinction between data, presentation, and the logic that connects them. It provides a strong foundation for organizing your code from the start.

When not to use it

As applications grow, the Controller can become a dumping ground for any logic that doesn't cleanly fit in the Model or View. This leads to the "Massive View Controller" anti-pattern, which is difficult to test and maintain. For these complex cases, other patterns like MVVM or VIPER may provide better separation of concerns.

One canonical example

In an iOS contacts app, a Contact struct is the Model, holding properties like name and phoneNumber. The ContactDetailViewController.swift class is the Controller. Its associated user interface, defined in a Storyboard or SwiftUI, is the View. When a user taps an 'Edit' button (View), the Controller receives the event, presents an editing screen, and upon saving, updates the Contact object (Model) and tells its View to refresh.