Complex software products have their own architecture. Despite the fact that every example is unique, for the most part, they all contain basic structure designs.

Patterns are repeatable and rather language-independent structures, so getting acquainted with only one of them implies understanding an entire pack of applications that share it.

It is fundamentally a general language to express thoughts, and Model-View-Controller (MVC) is one especially helpful pattern to learn, since numerous famous frameworks like Django (Python), Spring (Java), and Ruby On Rails (Ruby) are utilizing it.

The principle idea of MVC is dividing responsibilities between three components. The Model part contains business objects, the View represents the application and the Controller manages data flow between two of them.

The benefit of this design is that we can make various views from similar models, so we compose less code by reusing the current parts. Distinguishing one part from another is the primary principle to be guided by.

Every component has its associated files in the default Django format.

Suppose that we are creating an online magazine. The folder “travel” is the root of your website and the inner folder “places” is one of the applications. You can link the components with those files:

travel/
├── places
    ├── ...
    ├── models.py    # Model
    └── views.py     # Controller
├── travel
    ├── ...
    └── urls.py      # Controller
└── templates        # View

Let’s take a closer look at the files that you will need in order to make a web service.

Starting a New Project

For this example, we will utilize “travel” for a project and “places” for an application. If you need to get creative and utilize different names, don’t hesitate to change the given ones in the code.

The Django project is the foundation(root) of all code you are writing for the service, and it ought to have at least one application. To confine units of code with various business logic, you can create more of them. For instance, the travel project can have places, means_of_travel, cost, contact, and support applications.

With time the codebase turns out to be huge, dividing it into applications assists with controlling the complexity.

The django-admin utility helps organize the design of your project. You may create all these files manually, however utilizing the django-administrator will be a decent guide for the common structure of a project for you. Note that various versions of Django have distinctive default layouts, and whichever version you use, try to adhere to its provided structure: it will make your code simpler to maintain.

To create a project and the first application, run the accompanying in the command line:

django-admin startproject travel
cd travel
django-admin startapp places

Having executed these commands, you’ll get a whole file tree for the project with a piece of code. Now let’s get down to using our MVC pattern.

Model

travel/
└── places
    └── models.py

It’s ideal to have the same content for all users, however, if we need to alter it a bit, we need tools from Python interface.

The Model component includes all the database operations with the business objects in your project. A business object is an entity with custom attributes; it reflects a structured bit of information from your application which you need to store tenaciously or temporarily.

For instance, in a shop application, it tends to be a customer, an item, and a purchase; in a place, business objects can be the name, best_season, and reviews.

To keep your code clear, you should implement all operations with the business objects in the “models.py” module. The greater the codebase gets, the harder it is to maintain everything in one file, yet it’s a decent beginning point.

You may utilize User and Group models from django.contrib.auth.models: Django provides them with the box. The User is a registered individual in your web service and the Group is a collection of Users.

We’ll make a portion of those when we join a database for your project.

View

travel/
├── places
    └── templates
        └── blog
            └── index.html
└── templates
    └── base.html

Nobody will recognize what the service does except if it has some form of visual rendition. The View is represented by your web service. Basically, it is what the user sees.

The View component is stored in templates. Templates are files that support Django/Jinja2 template languages. In addition, they can include content with HTML, CSS, and JavaScript. Template language uses the capacity to utilize similar constructs you use in Python. It has an alternate syntax however a similar function words.

To make “templates” directory for the project and for the application, run:

# Unix
mkdir templates
mkdir -p places/templates/places

# Windows
mkdir templates
mkdir places\templates\places

In the project folder you keep base files for all other templates, applications folder contains only application-specific templates.

When you create “templates” directory for your application, you should name it “<application name>/templates/<application name>”. This redundancy is obligatory. If you use the same file name without the second repetition of <application name>, like “places/templates/index.html” and “news/templates/index.html”, then in both cases Django template loader will return the first file it found, which isn’t always what the user actually needs.

Controller

travel/
├── places
     └── views.py
└── travel
      └── urls.py

Views and models are good instruments, yet something ought to manage how they work together, which is where we turn to the Controller part.

The Controller comprises of two types of files: “views.py” and “urls.py”. In “urls.py”, you define the routing for your service. Routing is a procedure of matching request links with proper view handlers. You can include routes from “urls.py” files one into another, yet the fundamental will be “<project_name>/<project_name>/urls.py”. If you need to create routing files for every application, do it and include them for the main one.

In “views.py” you define view handlers, which play a mediator role between the Model and the View. A view handler is a function or a class that respond to requests. Since communications between client and server is an implementation of the HTTP protocol, handler answers with a status code. If the request was successful, the server protocol responds with 200 code. In case the requested page isn’t found, it will be 404; if the server is down, it’s 500. Different instances of codes can be found here .

Request to the Web Site

Now that you know how functions are divided between the components, let’s see how they interact when there’s a web site request.

1. A user sees a link or a button in a View, presses it, and creates a request.
2. The Controller receives the request.
3. It passes the request to the appropriate handler.
4. The handler calls Model methods to retrieve objects from data storage.
5. It chooses the View template to render a response.
6. A user sees a response.

Each part has its own methods and base classes in the Django package. You should separate the work with each component as Django developers do: this way other developers will understand your code and you will understand theirs.