How our Platform is built - MVC: Model, View, Controller

Background

MVC is short for Model, View, and Controller. MVC is a popular way of organizing software code. The logic behind MVC is that our software code is grouped into different parts and each has a different purpose.

Some of our software code holds the raw data for our platform, some of our code makes our platform look nice, and some of our code controls how our platform functions.

MVC is a way to organize our software core functions into these groups. This makes maintaining our platform and working on our platform with others much easier and cleaner.

The parts of MVC

Model: Model element typically reflects real-world things. This code can hold raw data, or it will define the essential components of our platform. For example, if we were building a to-do module on our platform, the model code would define what a “task” is and what a “list” is – since those are the main components of a to-do module. 

View: View element is made up of all the functions that directly interact with the user. This is the code that makes our to-do module look nice, and otherwise defines how our user sees and interacts with it. 

Controller: Controller element acts as a liaison between the Model and the View, receiving user input and deciding what to do with it. It’s the brains of the platform, and ties together the model and the view.

A real world example

It’s kind of like how you make a meal. You have a fridge with food, which is like the Model. The fridge contains the raw materials we will use to make a recipe. A recipe is like the Controller of your meal. Recipes dictate what ingredients from the fridge you use, in the recipe, and how long you cook them, etc. When you lay the table, dining table cutlery and crockery are like the View. The table let’s your friends interact with your Model and Controller’s handiwork.

MVC is helpful when planning our platform, because it gives us an outline of how our ideas should be organized into actual code. Taking our to-do example, from earlier and converting it to a construction contract, if we’re creating a project managers instructions module. This module will let us create instructions and organize all of them into lists.

The Model in our project managers instructions module might define what a “instructions” is i.e. whats on the form and that a “list” is a collection of instructions includes a, b and c; these would typically dictate how we would structure our database tables and API end points. The View code will define what the instructions and lists looks like, visually. The instructions could have large font, or have warnings in a certain colour; this is our user interface.

Finally, the Controller could define how and when a user can create an instruction, or send or reply to it, to action it. The Controller connects the View’s send/create button to the Model, so that when you click “create instruction,” the Model sends a new instruction.

Key takeaways

If you’ve looked at Contributing to our platform, you might have noticed that we will ask you to split the logic from the visuals.

In this article about MVC we given you a starting place to translate your ideas into code on our platform, and it also makes working with us to maintain our code easier, since you will be able to identify which code does what. Likewise, the MVC structure makes it easier for our developers to understand your contribution.

Thinking about how contributors interacts with other code in our platform is a significant part of programming, and learning to collaborate with our development team.

Thanks for taking the time to think about how our platform and your contribution fits together.