MVC is a design pattern that separates an application into 3 separate parts. Programmers do this to decouple the various parts of the application, which –
- Allows multiple developers to work on each section in parallel without affecting each other.
- Provides a standard paradigm to follow, eliminating the need to reverse engineer “spaghetti code” if appropriately implemented.
- Let’s you build and reuse components in other applications.
- Divide the front and the back end of the application (Back-end developers can handle the design and structure of the data, while front-end devs can manage the design, layout, and UX.)
* “Spaghetti Code” – Unstructured code that has a complex and tangled control structure. (Like a bowl of spaghetti.)
This article provides a very high-level description of the MVC. If you’re looking for something more in-depth, I would advise searching for an MVC tutorial for the language or framework documentation that you’re interested in. (See links below)
The MVC Components
The components are as follows –
Model – The central component that manages the data, rules, and logic. (Handles database logic)
View – The final output and representation of the information. (Handles presentation logic)
Controller – Validates and processes the input, before passing it to the model. (Handles business logic)
The picture below represents the information flow within MVC.
The view takes in the user request, sends it to the controller for processing, and the controller uses the resources from the model to display it to the view.
While MVC was created in the 1970s for personal computing apps, it was adapted for web use because of the separation of concerns. This emphasizes a modular design, making it easier for developers to edit a project, and reuse code for different apps.
In a web application, separate folders are created for the directory structure. For example, you can have a folder called “application”, containing 3 separate folders called “models”, “views” and “controllers”.
While this article doesn’t describe the actual implementation of the paradigm, I would like to stress the importance of the separation of concerns.
It is possible to use global variables; this can make it challenging to determine where the values within it are coming from.
Another issue is the use of GOTO statements, which performs a one-way transfer of control from one line of code to another.
Yet another issue is lack of modularity. (Having everything in one file, class module, etc.)
Does this mean you shouldn’t use global variables and GOTO statements at all? No, but you should be careful with their use to ensure your code is well-structured and readable. It’s easy to abuse the functionality, and make the code ill-structured (Spaghetti Code), and only readable by you.
Keep in mind, the purpose of MVC is to decouple the components for easy code reuse, parallel development and provide a defined flow of information.