(For more resources related to this topic, see here.)

Many applications start from something small, such as several hundred lines of code prototype of a toy application written in one evening. When you add new features and the application code clutters, it becomes much harder to understand how it works and to modify it, especially for a newcomer. The Model-View-Controller (MVC) pattern serves as the basis for software architecture that will be easily maintained and modified.

The main idea of MVC is about separating an application into three parts: model, view, and controller. There is an easy way to understand MVC—the model is the data and its business logic, the view is the window on the screen, and the controller is the glue between the two.

While the view and controller depend on the model, the model is independent of the presentation or the controller. This is a key feature of the division. It allows you to work with the model, and hence, the business logic of the application, regardless of the visual presentation.

The following diagram shows the flow of interaction between the user, controller, model, and view. Here, a user makes a request to the application and the controller does the initial processing. After that it manipulates the model, creating, updating, or deleting some data there. The model returns some result to the controller, that passes the result to view, which renders data to the user.

The MVC pattern gained wide popularity in web development. Many Python web frameworks, such as web2py, Pyramid, Django (uses a flavor of MVC called MVP), Giotto, and Kiss use it.

Let’s review key components of the MVC pattern in more detail.

Model – the knowledge of the application

The model is a cornerstone of the application because, while the view and controller depend on the model, the model is independent of the presentation or the controller.

The model provides knowledge: data, and how to work with that data. The model has a state and methods for changing its state but does not contain information on how this knowledge can be visualized.

This independence makes working independently, covering the model with tests and substituting the controllers/views without changing the business logic of an application.

The model is responsible for maintaining the integrity of the program’s data, because if that gets corrupted then it’s game over for everyone.

The following are recommendations for working with models:

• Strive to perform the following for models:
  • Create data models and interface of work with them
  • Validate data and report all errors to the controller
• Avoid working directly with the user interface

View – the appearance of knowledge

View receives data from the model through the controller and is responsible for its visualization. It should not contain complex logic; all such logic should go to the models and controllers.

If you need to change the method of visualization, for example, if you need your web application to be rendered differently depending on whether the user is using a mobile phone or desktop browser, you can change the view accordingly. This can include HTML, XML, console views, and so on.

The recommendation for working with views are as follows:

• Strive to perform the following for views:
  • Try to keep them simple; use only simple comparisons and loops
• Avoid doing the following in views:
  • Accessing the database directly
  • Using any logic other than loops and conditional statements (if-then-else) because the separation of concerns requires all such complex logic to be performed in models

Controller – the glue between the model and view

The direct responsibility of the controllers is to receive data from the request and send it to other parts of the system. Only in this case, the controller is “thin” and is intended only as a bridge (glue layer) between the individual components of the system.

Let’s look at the following recommendations for working with controllers:

• Strive to perform the following in controllers:
  • Pass data from user requests to the model for processing, retrieving and saving the data
  • Pass data to views for rendering
  • Handle all request errors and errors from models
• Avoid the following in controllers:
  • Render data
  • Work with the database and business logic directly

Thus, in one statement:

We need smart models, thin controllers, and dumb views.

Benefits of using the MVC

MVC brings a lot of positive attributes to your software, including the following:

1. Decomposition allows you to logically split the application into three relatively independent parts with loose coupling and will decrease its complexity.
2. Developers typically specialize in one area, for example, a developer might create a user interface or modify the business logic. Thus, it’s possible to limit their area of responsibility to only some part of code.
3. MVC makes it possible to change visualization, thus modifying the view without changes in the business logic.
4. MVC makes it possible to change business logic, thus modifying the model without changes in visualization.
5. MVC makes it possible to change the response to a user action (clicking on the button with the mouse, data entry) without changing the implementation of views; it is sufficient to use a different controller.

Summary

It is important to separate the areas of responsibility to maintain loose coupling and for the maintainability of the software. MVC divides the application into three relatively independent parts: model, view, and controller. The model is all about knowledge, data, and business logic. The view is about presentation to the end users, and it’s important to keep it simple. The controller is the glue between the model and the view, and it’s important to keep it thin.

Resources for Article:

Further resources on this subject:

• Getting Started with Spring Python [Article]
• Python Testing: Installing the Robot Framework [Article]
• Getting Up and Running with MySQL for Python [Article]