Основные принципы MVC

Зачем разделять код

Представьте файл, в котором вперемешку SQL-запросы, проверки форм и HTML. Его невозможно поддерживать: правка дизайна ломает логику, а смена базы данных требует переписать всё.

Поэтому код делят на слои с чёткими обязанностями. Классический способ — MVC.

Классический MVC

Главная идея: модель ничего не знает об отображении, а вид не знает, откуда взялись данные.

MTV — MVC по-джанговски

В Django те же идеи, но названия другие:

Путаница с «View» — частая ловушка: в Django view — это не HTML, а Python-функция, которая обрабатывает запрос. За HTML отвечают шаблоны.

Как это выглядит в коде

Модель — blog/models.py:

from django.db import models


class Post(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    published = models.BooleanField(default=False)

    def publish(self):
        self.published = True
        self.save()

Представление — blog/views.py:

from django.shortcuts import get_object_or_404, render

from .models import Post


def post_detail(request, pk):
    post = get_object_or_404(Post, pk=pk, published=True)
    return render(request, "blog/post_detail.html", {"post": post})

Шаблон — blog/templates/blog/post_detail.html:

<h1>{{ post.title }}</h1>
<div>{{ post.body|linebreaks }}</div>

Маршрут — blog/urls.py:

from django.urls import path

from . import views

urlpatterns = [
    path("posts/<int:pk>/", views.post_detail, name="post_detail"),
]

«Толстые модели, тонкие представления»

Хорошее правило Django-разработки: бизнес-логику кладите в модели (методы, менеджеры), а views держите короткими — они лишь связывают запрос, данные и шаблон. Тогда логику легко переиспользовать в админке, API и тестах.

Итог

• Разделение на слои делает код понятным и поддерживаемым.
• Django использует MTV: Model — данные, Template — отображение, View — обработка запроса.
• View в Django — это Python-функция или класс, а не HTML.