Understanding the Model-View-Controller (MVC) in Rails
The model-view-controller or (MVC) architecture is not unique to Rails. In fact, it predates both Rails and the Ruby language by many years. Rails, however, really takes the idea of separating an application’s data, user interface, and control logic to a whole new level.
Let’s take a look at the concepts behind building an application using the MVC architecture.
MVC in Theory
MVC is a pattern for the architecture of a software application. It separates an application into the following components:
- Models for handling data and business logic
- Controllers for handling the user interface and application
- Views for handling graphical user interface objects and presentation
This separation results in user requests being processed as follows:
- The browser (on the client) sends a request for a page to the controller on the server.
- The controller retrieves the data it needs from the model in order to respond to the request.
- The controller gives the retrieved data to the view.
- The view is rendered and sent back to the client for the browser to display.
This is the kind of official guide, you can find everywhere when you search for MVC architecture.
So now, I’m going to go into an unofficial guide which is inspired, by Ruby on Rails Seminar.
Understanding MVC: an analogy
We have a couple characters in the unofficial guide. There is our ‘Model’, Madeline, who is very smart, she loves data, knows all about data, but she’s a little but anti-social and she doesn’t usally interact with much peoples.
Next, threre’s our “View”, Vicki, who is georgous, but she’s not so smart and lastly there’s our “controllers” ,Cailtyn who really like ordering people around, but doesn’t really like doing thing by herself.
Lets say our characters all happen to work in CVS
Scenario 1: A customer asks Vicki for a piece of candy from right in front of the register..
Well, Vicki doesn't really know what to do, so she turns around and asks Caitlyn: " Caitlyn, what do I do? This customer just asked for candy."
Caitlyn our very controlling manager says: "Well, the candy is right there, just give it to them!". And so Vicky says, "Oh, okay, good". She hands the candy back to the customer.
In this case, we’re not even dealing with our Model, this is just a user went and clicked on a link to your web page. The View is stupid, doesn’t really know what to do, so it has to ask: “what do I do with this information?”.
The Controller hands back the appropriate page as result the View can display it.
Scenario 2: A customer asks Vicki for a cup from the back…
Vicki says: "Oh my gosh, I have no idea what to do". And she ask to Caitlyn the manager again.
Caitlyn turn around, yells at Madeline our Model:"Madeline go get a cup from the back!!".
Madeline grabs the cup, hands it back to Caitlyn our manager who hands it back to Vicky, and finally present the cup to the client.
I n this case, it slightly more complicated, but basically the idea is pretty similar. Something happens on the Front-end, the user ask for something.
The View doesn’t really know what to do, ask the Controller.
The Controller tells the View whether just hand back a certain amount of data to the user or go get some data from the back; hand it back to the View who can display it to the user.
Separating a software application into these three distinct components is a good idea for a number of reasons, including:
improved scalability (the ability for an application to grow)–for example, if your application begins experiencing performance issues because database access is slow, you can upgrade the hardware running the database without other components being affected
ease of maintenance—as the components have a low dependency on each other, making changes to one (to fix bugs or change functionality) does not affect another
reusability—a model may be reused by multiple views
I think that’s like a useful way of thinking about MVC