The Model-View-Controller (MVC) pattern can seem very daunting to newcomers, but in reality it’s a very simple concept once understood. In this article, I’ll make use of an analogy to try and make it as simple as possible to grasp.
What is MVC?
The MVC pattern is by no means a new concept. In actual fact, it was originally formulated way back in the 70s with the idea in mind to keep the business logic (the model) separate from the user interface logic (the view). The diagram below illustrates, very simply, how a typical MVC application works.
Let’s have a closer look at what each component of an MVC pattern is responsible for.
The model is used to store the data for the overall application. In many cases, the data exists in some kind of separate database and the model acts as communication between the website and the database. It will typically allow data to be created, read, updated, and deleted (A.K.A CRUD).
The model will only be responsible for one thing: handling the data. It doesn’t care what happens next, after the data is passed to the view or controller, or what happened before when the user initially made the request, so the model’s functionality is completely abstracted. This concept is known as the separation of concerns (SoC).
A view is, effectively, a visual representation of the model. In modern technologies and frameworks, a view will typically contain the HTML code that will be output onto the page when a user makes a request to the page.
The controller is the component that handles the user interaction – effectively acting as a communication layer between the user and the model. When a user makes a web request by visiting a webpage, the controller will collect the relevant information from that request and pass it onto the model. The only logic the controller will contain is the logic required to organise the data from the request. A controller will never alter the data – that’s the model’s responsibility.
Anybody who doesn’t have a background in programming and design patterns will likely be very confused at this point. Now I’ve thrown all that technical jargon at you, let’s slow down and simplify things a bit.
The Television Analogy
Some people like to think of MVC as a television. The television is the view, representing the data (the TV show, in this instance) to the user (you). When the user presses a button on the remote (the controller), the remote will process the request and communicate with the model to retrieve the appropriate data.
The model, in this case, is the cable provider – where the data is stored and manipulated. So when the user presses the “3” button on the remote, the controller will talk to the cable provider: “Hey! Give me Channel 3!”. The model will return the data (the TV show airing on Channel 3) back to the view (the television) for the user to watch!
Hopefully that cleared things up for a lot of confused newcomers. I’m always open to ideas, suggestions, and requests so feel free to contact me if you wish to get in touch!