What the hell is an MVC?
It’s becoming easier than ever to build web applications these days (ask Mum). There are as many web frameworks available for use, as there are applications, making it difficult to learn any one of those in peace. Even if you don’t program, you’ve almost certainly heard about “Ruby on Rails” or “the Zend framework”. Those are only two of the many that utilize the MVC.
MVC. Short for Model-View-Controller. Let me explain in detail. Most applications have a GUI component that users can interact with. There are buttons to click and forms to fill.
What happens in the background when you click those buttons? Where does the stuff you fill go?
Models are data structures. All your kewl names (Suppandi, GaryTHEFish, missTika) - they’re attributes of Model objects. Model objects are instances of Models. An attribute is what helps discern one model object from another. So while it may not matter much how cool your name is, it’s existence is important. Depending on the application, you need to have a nick. An email address. A profile picture.
Most of these attributes by themselves are just raw datum. When you put that together you’ve made something useful - a user. An instance of the User Model! If you know what OOP is, this should be your gotcha moment :)
Typically, modern web applications rely on many models. All the world’s status updates are objects of probably the Status model. All statues possess exactly the same attributes - the text with the status itself, the number of likes on it, the time it was created. In the database, they are probably identified with let’s say, a unique serial number. So you can look up Status #56 and you can check if the author liked it himself. Models map to databases.
Moving on to views. When you want to display the statuses neatly on a web page, you’ll probably want to add a blue border around it. Maybe make a few red buttons blink on one side too, so it attracts people to click on it, right? Views help you with that. What you supply to the user’s browser is a view. Views contain the forms, the buttons, the text - if you’re just a normal user browsing the web, you’re pretty much interacting with views.
So how are models and views related? For most applications, views are what allow users to interact with model objects. So views contain stuff like the </html> for the forms, which renders on the user’s browser, and which the user can use to enter fancy nicknames. Make sense? Great. Mum is proud of you.
Now look at this form.
User enters the nick on the form and clicks the submit button. The goal is to associate it with an object of a User model. But… who facilitates this transaction? The stuff users enter are on the form right? Now how the heck does it land inside a database? How does it associate with a model?
The Controller! Controllers receive all the content of the form, create/update Model objects with those attributes, and then a database entry happens. How Sparkly!™
But that’s not all the controller does! Let’s suppose you were lying about your email and it was already owned by someone else. Mum wouldn’t be proud of that, right?
The controller will help find out if the database entry was successfully handled. If the User model allows multiple users to possess the same email, then cool. If it doesn’t, the controller will decide what to do next (hint, probably ask you to re-enter a different one?)
An important thing to add: MVCs are almost invariably accompanied by Routes. I honestly don’t know why it isn’t called an MVRC or something (it probably doesn’t make a great acronym), but it’s important for anyone learning about MVC to know what Routes are. Routes help you create the URIs that we see on browser address bars. Routes will decide what method of let’s say, the registrations_controller is to be associated with the signup page. You’ll understand better once you’ve worked on an MVRC system such as Ruby on Rails.
Alright, I guess now we’re equipped enough for some philosophy. FAQs:
- Why MVC?
- It’s a useful paradigm that helps you amicably separate your presentation from your application logic & the data structures you’re dealing with. Frameworks very powerfully let you exploit that, hence making possible for you to come up with powerful applications in very less time. Since the development is now divided, it’s also easier to let experts deal with different areas in which the application needs attention.
- Easier to spot where you are going wrong.
- Where to go from here?
- Simple, make an application. Try any MVC framework for yourself. It’s sometimes hard to absolutely stick to MVC guidelines, but if your thing works, I don’t see why it’s a concern.
Hope this was a quick guide for anyone who wanted to know What the hell an MVC is. :) Cheers, and remember to share if it helped you! Feedback welcome!