In the early years of software development, applications were complex monoliths with logic and UI inextricably entangled. In the late 70s, the designers of the Smalltalk programming language developed a different way to architect applications — one that separates the “business” logic of software from the elements that deliver the interface to the user and accepts their instructions.
That principle of software architecture — MVC, or Model-View-Controller — later become the design pattern for the vast majority of web applications and the frameworks on which they are based. PHP frameworks like CodeIgniter, CakePHP, and Laravel are designed to make building MVC-style applications as easy as possible.
So, what is MVC? The best way to understand MVC is to understand the way in which it separates concerns in application architectures.
The model is at the heart of MVC applications. It’s where the main logic and the data objects that constitute the core functionality of the application are developed. You can think of models as a representation of real-world knowledge that the application stores, processes, and delivers to the end-user (although the particulars of the delivery take place elsewhere).
The model is responsible for getting data from a database, packaging it in data objects that can be understood by other components, and delivering those objects — most of which will happen in response to input from the controller.
The controller is how the user interacts with the application. Usually, the controller takes user requests from the interface (often in the form of HTTP requests for web applications) and calls the model, which retrieves and processes the data, before returning it to the controller. The controller will then use the appropriate view to display those results to the user.
The view is where the data provided by the model is presented to the user. A view oversees the visual (or other) interface elements — it selects, filters, and arranges information supplied by the model.
Different views can present information in different ways — an obvious implementation of multiple views would be to handle the display of information on a mobile or desktop browser.
Keep in mind that there are many different ways of implementing an MVC architecture, and the above is a high-level sketch of the basic principles and doesn’t reflect any particular implementation.
Why Use MVC?
Developers use an MVC architecture for the same reason web designers use HTML (the model) and CSS (the view) instead of mixing structure, data, and layout together — the separation of presentation and data reduces complexity and allows developers to — for instance — build new front-end interfaces without having to change the core logic. MVC reduces the complexity of web applications and makes them easier to maintain.
Why Use A Framework?
MVC frameworks do most of the basic scaffolding work of building an MVC application. Developers simply have to extend the structure provided by the framework.
As you might imagine, building an MVC application from scratch is complex — frameworks make it a great deal easier to get started. Developers can focus on building the main logic of their applications and the interfaces through which users will interact with that logic, rather than having to worry about the complex business of organizing the components and how they will interact.