MVC stands for Model-View-Controller and is a software architecture pattern commonly used to develop software applications. Although originally designed for desktop computing, MVC has been widely adopted as a design for World Wide Web applications in major programming languages.
The Model-View-Controller pattern was originally created in the late 1970s by Trygve Reenskaug, a Norwegian computer scientist, while he was working at Xerox PARC (Palo Alto Research Center). The MVC pattern was intended to help separate the concerns of the user interface design from the underlying application logic, making it easier to develop, test and maintain software.
Since then, the MVC pattern has become a widely used design pattern in software development and has been applied to many different types of applications and platforms, including web development, desktop applications, mobile apps, and more. Although there are several implementations of MVC, the most important point of the pattern remains the same - the division of responsibility.
There are other patterns similar to MVC, such as MVP (Model–View–Presenter) or MVVM (Model-View-ViewModel), but these are beyond the scope of this article. In this article, we will focus on a traditional MVC architecture for web applications.
If you have worked with frameworks like Laravel, Ruby on Rails, or Flask, you may already be familiar with the MVC architecture. It divides the program into three interrelated components:
Model
View
Controller
Model
The Model often represents a table in an application's database and is responsible for reading and writing data, as well as persisting the application state.
In MVC, the Model is designed to be independent of the View and the Controller. It can be tested and developed separately from the other parts of the application.
View
The View is responsible for displaying data to users and handling user interaction. In the traditional interpretation of the MVC pattern, the View should not communicate directly with the Model. The Controller should update the View after receiving information from the Model about any changes to the data.
However, in practice, direct access to the Model is not uncommon, for example in small or simple applications. While this approach can simplify development in some cases, it can also make code more difficult to maintain and test over time, as changes to the Model can break views that rely on it. It also violates the principle of separation of concerns, which can make the code less modular.
Controller
The Model and the View are connected together through controllers. The Controller is responsible for receiving and processing user input, manipulating the Model (fetching/creating/updating/deleting data), and updating the View (returning the appropriate response to be rendered).
Visual Representation of MVC for a Web App
Below is a diagram of one possible take on the MVC pattern for a web application.
Let's take a closer look at what is happening here:
A user enters a URL in a browser and sends a request to a web application to open a specific page, in our case https://website.com/pages. Similarly, a user can send other types of requests, for example, a POST request from a web page to create a new record in the database.
In order to know which page/response to show the user based on their request, the web application has a list of routes. Those are, essentially, URL patterns associated with different pages which the application tries to match with the requested URL. Routes are associated with controllers, or rather with a specific function inside the controller known as a controller action. If the application finds a matching route (/pages in our case), it invokes the route-related controller action. If the route is not found, the application returns a 404 error.
With help of the routes, the PagesController action is called and that controller receives the user's request. PagesController then goes to PageModel to retrieve the necessary data, in our case, a list of pages. In other cases, the Controller may ask the Model to create a new record or modify an existing one based on the user's request.
As discussed previously, the Model often represents a table in an application's database, in our case, PageModel is connected with the pages database table.
The Model makes a request to read or write data from the database. The database executes the specified command, in our case, it is fetching all pages from the pages table and returns the result (data) to PageModel.
PageModel returns the pages data to PagesController.
The Controller passes the data received from the Model to the View. Finally, the View renders the requested page using data received from the Controller. The View is the last page a user sees in their browser.
The end, I hope this information was helpful, stay tuned for more content :)
Top comments (0)