Model–View–Controller otherwise known as MVC, is a software design pattern commonly used for developing user interfaces that divides the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
MVC became one of the first approaches to describe and implement software constructs in terms of their responsibilities. MVC is based on the theory of separation of concerns. Trygve Reenskaug introduced MVC into Smalltalk-79 while visiting the Xerox Palo Alto Research Center (PARC) in the 1970s. In the 1980s, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library. Only later did a 1988 article in The Journal of Object Technology (JOT) express MVC as a general concept. The MVC pattern has subsequently evolved, giving rise to variants such as hierarchical model–view–controller (HMVC), model–view–adapter (MVA), model–view–presenter (MVP), model–view–viewmodel (MVVM), and others that adapted MVC to different contexts.
The use of the MVC pattern in web applications exploded in popularity after the introduction of NeXT’s WebObjects in 1996, which was originally written in Objective-C (that borrowed heavily from Smalltalk) and helped enforce MVC principles. Later, the MVC pattern became popular with Java developers when WebObjects was ported to Java. Later frameworks for Java, such as Spring (released in October 2002), continued the strong bond between Java and MVC. The introduction of the frameworks Django (July 2005, for Python) and Rails (December 2005, for Ruby), both of which had a strong emphasis on rapid deployment, increased MVC’s popularity outside the traditional enterprise environment in which it has long been popular.
So what is MVC and how do each individual components work together?
Model-Takes care of the app’s logic. It is usually represented by a OOP(Object Oriented Programming) Class. It defines a class then maps it to a table in the database where they will converse back and forth. The model is responsible for managing the data of the application. It receives user input from the controller.
View-This is exactly what it sounds like. It is the user facing component where data is presented to a user. The view renders presentation of the model in a particular format.
Controller-I usually refer to the controller as the traffic cop. When the app receives a request of some sort the controller takes control(see what I did there) and then routes the needed actions. It tells the model what data to grab from the database. It tells the view what data to present to the user. So on and so forth. The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.