What is MVC?

A pattern older than Rails itself

The web: request-response walked through the full path a Rails request takes: Puma, middleware, router, controller, model, view. This course looks at something narrower: MVC itself, as a design pattern rather than Rails plumbing.

Trygve Reenskaug developed Model-View-Controller in 1979 at Xerox PARC, years before "design pattern" was a common term. It later became the architecture behind Smalltalk-80's graphical interface, one of the first GUIs, long before Rails or the web existed. Rails didn't invent MVC; it adopted a pattern that had proven itself for two decades.

Three roles, one job each

MVC splits an application into three kinds of responsibility:

Model      → data and business rules: what IS true, what CAN happen
View       → presentation: how something is DISPLAYED
Controller → orchestration: which Model to ask, which View to show

Each role has a job the other two don't do. A Model never decides how something looks on screen. A View never decides whether a business rule passes. A Controller holds no business logic; it directs traffic between the other two.

Why split anything at all?

Without the split, one file could hold "check if the user may do this", "calculate the total" and "generate the HTML", all tangled together. MVC treats these as three kinds of work. Keeping them in three places makes each easier to find, test and change without breaking the others.

Key takeaways

• MVC predates Rails by decades: Trygve Reenskaug, Xerox PARC, 1979, later Smalltalk-80's GUI architecture.
• Model owns data and business rules, View owns presentation, Controller coordinates them.
• Each role stays out of the other two's jobs; that separation is the point.
• Separate places make each kind of work easier to find, test and change.