Explaining concepts that can be hard to understand. You can expect relatable examples without jargon, foo, bar, and math examples.
Jump to:
Have you heard of this MVC thing? If not, you might look it up and run into a description like this. ⬇️ 😬 If you'd like an easier to understand explanation, you're welcome to jump down to the TechItEasy explanation.
Scary Jargon-filled Explanation
MVC (Model-View-Controller) is a pattern in software design commonly used to implement user interfaces, data, and controlling logic. It emphasizes a separation between the software's business logic and display. This "separation of concerns" provides for a better division of labor and improved maintenance.
The three parts of the MVC software-design pattern can be described as follows:
- Model: Manages data and business logic.
- View: Handles layout and display.
- Controller: Routes commands to the model and view parts.
source: MDN
Does this chart make sense? If not, I bet it will once you're done reading this TechItEasy explanation.
TIE: MVC framework
Wait! What's a Framework?
Glad you asked. We should probably know that before we get into some real life examples.
A framework is a set of pre-made pieces used to help speed up building and give a standard way to make applications. These pre-made pieces of code are typically called components. Frameworks can include components for user management. User management may include creating, reading, updating, deleting, send forgotten password emails, etc. Frameworks are helpful because they remove the need to write code for things that get used all the time.
Why Use Frameworks?
If you haven't heard it before, DRY stands for Don't Repeat Yourself. This is an ideology that says we shouldn't have to write the same code multiple times. If you wrote code on how to make a cat, you wouldn't want to write it again and again for every cat that comes into existence. In this way, MVC has components that make it so the common things don't have to be written again. MVC frameworks help keep your code DRY.
Of note, MVC frameworks follow a pattern to help you think of each part of an app separately. There are other design patterns, but it seems MVC frameworks are most common. I'd guess they're common for a reason.
MVC frameworks simplify the building process. That's not to say it's easy, but to mean that it's generally easier than building a whole web app without a framework.
Right, now, What are the M, V, and C?
Models
Models are like a template or chart for data/info needed for an item or object. For example, if your pet has data. Some of the data is needed and some is nice to have but not required. Models allow you to say what each piece of data is whether or not it is required, and lots of other things. Here's a table representing a dog model.
| Name | Date Type | Required? |
|---|---|---|
pet_name |
string | no |
spayed_neutered |
boolean | yes |
weight_lbs |
number | yes |
favorite_toy |
string | no |
Each name in this table represents a column in a database. You could imagine it looking like this.
| id | pet_name | spayed_neutered | weight_lbs | favorite_toy |
|---|---|---|---|---|
| 2 | Cheeto | true | 11.1 | BALL |
| 5 | Remmy | true | 12.8 | fishing pole |
| 6 | Wiley | true | 32.3 | beheaded dragon |
| 8 | Chip | false | 0.00440925 | crashed helicopter |
| 9 | Beans | true | 9.6 | random piece of foam |
Notice we've added IDs. Sometimes these are referred to as uid which is short for "unique identifier". In this case, each new pet is given a number that belongs to them. We use an ID because everything else can change and we need to have access to reference the specific pet.
Views
Views are the code behind the pretty stuff. This is your front-end user interface code. It's generally some combination of HTML and CSS. It can also be done in other languages that get rendered/translated into HTML and CSS.
Controller
Controllers do the controlling. Good? Make sense? No? I didn't think so. Controllers are where you'll write code on how things should work. This is where the logic goes.
Okay, but How Do They Work Together?
Controllers change models. Models change the views. Views send info to the controllers. Controllers sometimes send info back to the views. For extra confusion, models also talk to databases. Are you confused yet? How about we jump into some real-life MVC frameworks.
Example with Your Body
Whether you knew it or not, your body has models, views, and controllers.
Models
You could look at your skeleton as a model. Your bones define the shape and structure of your body. Regardless of what bones you do and don't have, they are your model. By themselves, bones don't do anything but give structure. If you want the bones to look pretty, you'll need your views. For them to do things, you'll need controllers.
Views
Next time you get out of the shower, look in a mirror or take a selfie. What you see is your view. For your body, the view is your physical appearance. Your view includes skin, textures, colors, hair, and anything else that naturally exists as part of you. This would be like the HTML structure of a web page.
If you choose to, you may put clothes on, use prosthetics, move parts to get the right shape, use jewelry, use assistive devices, or do any number other things to change the outward appearance of your body. This is very similar to using CSS to make a webpage more interesting.
Views can send info to controllers. In the case of your body, you could imagine that something happened or you sensed that it happened. For example, a mosquito may land on you. Whether you saw it or felt it, this was your body's view send data to your controller.
Controller
Your brain contains your controllers. Your brain houses all of the logic for your body. If a mosquito landed on you, your avoid_mosquito_bite controller is then going to send out a job for you to move your limbs and address the intruder.
Your brain knows how to handle things because you have taught or coded it to do them. You may not recall, but at some point you may have learned how count, read, brush your teeth, and all of your other daily tasks.
There are also controllers for things you never had to learn. They came pre-coded. Most of the time, we have the ability to breathe, process food, pump blood, and all sorts of other body processes. These pre-coded bodily functions are similar to an MVC framework's pre-built controllers for things like login and user profiles.
Now for How They Work Together
If you've lived this long, I think it's safe to assume you know your skin works with your skeleton and your brain and vice versa.
Your brain (controller) uses logic to tell your skeleton to move in certain ways. When your skeleton (model) has been told to move, your skin (view) moves and changes with it. When your skin receives input from the outside world, it will send a message to the brain. From there, the brain may tell the skeleton to move a different way.
Your skeleton (model) may also talk to a database. In this case, we could call your memory the database. Every time your brain tells your skeleton to change shapes, your memory saves it for future reference.
I think, at this point, this chart may make a little bit more sense. What do you think?
Still having trouble? Try thinking of the sites you use regularly. Their controllers will likely include actions like creating, reading, updating, and deleting. The models are going to be the things those actions happen to (ie characters, posts, products, etc). The views are the pretty (or maybe not) visual part you see on your browser.
Other Things Worth Knowing
There are plenty of options when it comes to MVC frameworks. There are even multiples for different languages. Here are a few popular ones and the official getting started projects.
| Language | Framework | More Info |
|---|---|---|
| Python | Django | Polls tutorial |
| Ruby | Rails | Blog Tutorial |
| JavaScript | Angular JS | Catalog tutorial |
| .NET | ASP.NET | ASP.NET Getting Started |
| PHP | Laravel | Laravel Quickstart |
MVC frameworks make it easier and quicker to create full stack apps than it would be if you wrote everything from scratch. It will take some time to learn how things are put together, but you will reap the reward of being able to make things relatively quickly. Once you've got the basics, congrats! You're a full stack developer.
Top comments (0)