MVC
Last updated
Last updated
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.
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 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.
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).
The browser makes a request (such as )
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 : It gives orders without knowing (or caring) how it gets done.
