# MVC ## Model View Controller **Model View Controller (MVC)** is a **3-tiered architectural software design pattern** for implementing user interfaces. It divides a given software application into three interconnected parts, to separate internal representations of information from the ways that information is presented to or accepted from the user. In addition to dividing the application into three kinds of components, the MVC design pattern defines the interactions between them. * A **Model** stores data that is retrieved according to commands from the **Controller** and displayed in the **View**. * A **View** generates new output to the user based on changes in the **Model**. * A **Controller** can send commands to the model to update the **Model's** state. It can also send commands to its associated **View** to change the it's presentation of the **Model**. ![Model View Controller](/files/-L9huAKjddqIZBRAIRit) ## The flow of request & response Alright, so you already know the basics of the Request response pattern - the MVC pattern deals with what is happening with the request by your web- and application server and the application itself. At the and, an appropotiate responce is sent back to the client (the browser or whatever has made the request) and forgotten about. Instead of a sterile **“3-tiered architecture”** walkthrough, it's more fun to imagine a story with **“fat model, skinny controller, dumb view”** . **Models** do the *grunt work*, **Views** are the *happy face*, and **Controllers** are the *masterminds* behind it all. Think about this flow: * The **browser** makes a request (such as ) * The **web server** (WEBrick, etc.) receives the request. It uses **routes** to find out which **controller** to use. The web server then uses the **dispatcher** to create a new controller, call the action and pass the parameters. * The **Controller** do the work of parsing **user requests** (data submissions, cookies, sessions and other “browser stuff”). They're the pointy-haired manager that orders employees around. The best controller is [Dilbertesque](http://dilbert.com/): It gives orders without knowing (or caring) how it gets done. * **Models** are Ruby classes extended by ORM methods. They talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting. They're the chubby guy in the back room crunching the numbers. * **Views** are what the user sees: HTML, CSS, JavaScript, JSON. They're the sales rep putting up flyers and collecting surveys, at the managers direction. Views are merely puppets reading what the controller gives them. They don't know what happens in the back room. * Finally, the **Controller** returns the **response body** (HTML, XML, etc.) and **metadata** (caching headers, redirects) to the server. The **server** combines the raw data into a proper **HTTP response** and sends it to the client to be presented to the user. * The **web server** is the invisible gateway, shuttling data back and forth (users never interact with the controller directly). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://craftacademy.gitbook.io/coding-as-a-craft/extras/model_view_controller.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.