Understanding The Model View Controller Design Pattern
For entry-level, web development enthusiasts and beginners alike, understanding the Model View Controller architecture can at times be a daunting task. In a variety of cases, its usage and implementation in projects may be discouraging when getting your feet wet in the early stages. In this article, I have tried to explain the basics of the MVC concept. The concept can be implemented differently in other types of programming. My explanation is, however, pegged on a web development point of view. Also, as a result, the illustrations won’t touch on any specific language as I try to map out how everything connects. A normal web application can have many moving components working together as a unit, for the application to work. The Model View Controller architecture is more often than not, a part of these moving components in the application. MVC is one of the most frequently used industry-standard concepts in creating scalable and extensible projects. It does this by separating application functionality inside of projects. So what is MVC? An analogy of what all this is all about can be explained using a user interacting with a website. A user initiates a process with a click to view a certain page. The web application takes this instruction, looks for the requested page and displays it. All this is taking place in the background (back-end). The rendered page is a result of a series of processes that the application on which the website sits does the work. It has to follow a laid down set of instructions to render the requested page. The Three Components of MVC Model handles data logic. What this means is that the model handles the graphical representation of the data in storage. The storage, in this case, is a database. It handles the getting and manipulation of the data in the database. Some experienced programmers often call it the brain of the application. This is so because it always communicates with both the Controller and can at times manipulate the View as well. View is the visual part of the application and handles what the user sees (User Interface). The view is usually made up of HTML/CSS. Its interaction with the Controllers can allow it to pass values from the Controller. What this means is that its elements and values can get manipulated by the Controller. A plain HTML/CSS cannot have these functions performed in them. As a result of this, modern frameworks have their respective template engines to allow for functions such as these to be possible. (Erb in the case of ruby on rails and jinja2 in the case of Flask). Controller is what receives the various inputs from either View or URL(routes). The inputs are usually user input. It handles the processing of the user’s requests. When a user clicks on a link on a profile page, for instance, the command it receives is usually the GET request. During a form submission by the user in the page, the command received as a result of this is usually the POST request. Other requests include the PUT or PATCH and DELETE. The controller handles the retrieval of data from the Model and passes that data to the View. It does somehow act as a middleman between the Model and the View. MVC in Action When a user clicks on a link, let us say a profile in this case, » Read More
Like to keep reading?
This article first appeared on hackernoon.com. If you'd like to keep reading, follow the white rabbit.