4.1 MVC

MVC (Model-View-Controller) is the most deeply ingrained architectural pattern in enterprise applications. It splits an app into three layers, using separation of concerns to stop "data, UI, and logic" from tangling together:

• Model: data and business rules. It doesn't know what the UI looks like.

• View: presentation and rendering. It only "draws" the model, holding no business logic.

• Controller: receives user input and coordinates the model and view.

The lab below lets you click a button and watch a request light up the one-way data flow "Controller → Model → View" in turn.

Why split into these three layers

You've probably felt the cost of mashing them together: a "mega-function" that queries the database, assembles HTML, and handles clicks — change one part and everything trembles. MVC's benefits:

• Independent substitution: one model can drive multiple views (web, mobile, API).

• Independent testing: business rules live in the model and can be tested without a UI.

• Parallel development: frontend builds the view, backend builds the model, and the controller defines the contract.

The responsibility board below lets you assign a set of responsibilities to their rightful layer — building your intuition for "what goes where."

Variants and reality

MVC has many evolved forms sharing one core idea:

• MVP (Presenter): the view is more passive and logic concentrates in the Presenter, easing testing.

• MVVM (ViewModel): data binding keeps the view in sync with the ViewModel automatically; common in frontend frameworks (Vue, WPF).

• Backend MVC: Spring MVC, Django, and Rails route requests to controllers that call models and pick templates.

Whatever it's called, the test is always: has business logic leaked into the view? have UI details seeped into the model? Hold that boundary and you hold MVC's value.