It has been about a year since I decided that I want to switch over to computer science, and since then it has been an exciting journey learning about how computers worked. All my life I have been a fairly casual computer user, and for me computers have always been something like magic to me. I would click on the button and it would take me to a website, or I would press my keyboard and it would make my character jump on the computer.
So when I participated in a coding bootcamp at UC Berkeley extension and I was told that computers primarily are nothing more than a large sequence of 1's and 0's, it was like being told about the quantum universe, when I hadn't even understood basic physics yet. Eventually I learned about basic concepts concerning web development, and started feeling my way through this mysterious world of computers using a lot of console.log.
One of the topics which has since stuck with me, and really make sense of what a web page is was the idea of Model-View-Controller, which I want to explore more in depth today.
First let's explain this diagram to understand the MVC model, which is the basic logic behind most webpages.
We'll start at the top with the model. What the model is, is the fundamental basis for everything in computers which is just data. Everything on a web application from checking your online status (boolean), all your important tweets (string), and how many likes you got for those tweets (integer), are all instances of data. These are the building blocks or actual matter consisting the web application. The way I like to look at it is that it is the physical matter of computers. One important note to make about the model, is that because it is the actual data, it is not dependent on the view or controller.
Second we have the view. Anytime we look at a computer screen we are looking at some representation of data. Whether it is through a simple CLI program that just involves text, or a complicated web page that uses graphical interface, we have the 'view' of our data. What this part of the MVC provides is what can be seen as a visual filter for our data and is responsible to choose what parts of our data are represented and how. The view can be independent of the model and controller (f.e. a webpage displays basic text saved in a database) or it can be controller itself and therefore dependent on the model (like a table or calendar where users can directly manipulate).
Last but not least we have our controller. The controller is, as the diagram shows, what the user interacts with in order to interact with or change our data in our model. An application would be meaningless for a computer to just display a static piece of data. Instead, the point of an application is for users to be able to manipulate that data and interact with it in some way meaningful to the user. A controller can allow our user to interact with the model/data in many different ways, a typical example being the button that a user can click to communicate to our model. What actually represents a controller on an application can be tricky to grasp, because technically our changes to the data must represented in our view and model, and is dependent on them. I like to see it as the tool responsible for 'movement of data'. One useful convention to define what a controller can do is represented by the CRUD, which stands for create, read, update, and delete (all movement of data). You can read more about that here. (https://stackify.com/what-are-crud-operations/)
At face value, MVC is a very basic concept, but I think that is what makes it such a useful overarching model to describe programming in general.
In my current bootcamp at Flatiron, our cohort was given this file to work on.
The whole class and I just stared at the folder structure for about 15 minutes not even sure where to start. But as with anything simple, we just need to break it down into its parts.
After reviewing the MVC model, I referred back and noticed a whole section of the file structure at the top was just exactly that structure in our app folder, which is the actual web application structure we'd expect. All of the logic of that complicated folder structure can just be summed up into that table at the top.
So now we understand what the application part is doing. But as I look back to the objective of our lab, which was to use ActiveRecord to make data models and associations, I could make sense and organize our tasks into categories.
First we have the ActiveRecord migrate functions, which actually make our data tables with SQL. This part of the project functions like our model, since we are determining how the data will be organized and what categories of information there will be.
Next, we have our models, where we can determine how this data model will relate with other data models based on things like matching keys, and what belongs to what. There are also other functions we can construct to do special things with our data.
I believe just like the world is structured in 3 dimensions, the MVC model provides a useful way to understand how data is structured. The computer program is not just data, but the interaction of data with uses of controllers and views. Conversely, (like how I used to perceive computer applictions) is not just a magical GUI interface, but is based in data that is defined in our system. These things all ultimately work together to compose of a computer application. Understanding that structure of many different roles and how they work together to provide one application provided by MVC, helps us understand and make map our sense of what programming is.
Top comments (0)