Программы
Шаблон разработки ПО — Model View Controller (MVC)

Шаблон разработки ПО — Model View Controller (MVC)

MVC - один из самых распространённых архитектурных шаблонов разработки. Часто используется в различных фреймворках. В том числе и в Django.

Model-View-Controller, или же "Модель-Представление-Контроллер" - это паттерн (шаблон), рекомендующий разделять приложение на три части (в некотором смысле - также "трёхзвенная архитектура"). В сущности, приложение рекомендуется разделить на:

  • Модель - для изолирования логики работы с данными.
  • Представление - на этом уровне изолируется взаимодействие с пользователем.
  • Контроллер - содержит логику, необходимую для интерпретации пользовательских действий и отражения их в модели. И наоборот.

В своё время, как и многие замечательные открытия 70-х / 80-х годов (тот же графический интерфейс, который позже появился в Apple Lisa) MVC был придуман в компании Xerox. И долгое время данный паттерн был "одним из", но при развитии веб-фреймворков, получил вторую жизнь. В частности, используется в самых популярных веб-фреймворках языков PHP, Python, Ruby - Symfony / Laravel, Django, Ruby on Rails.

Суть паттерна Model-View-Controller

Каждую хранимую логическую сущность мы можем представить в виде модели. При чём в каждой конкретной модели мы можем реализовать методы, предоставляющие удобный доступ к данным. Также можно реализовать базовую модель, от которой прочие будут наследоваться для определения общих методов, предоставляющих общий интерфейс для всех моделей - всё же для почти всех моделей будет логично иметь базовые функции: Create, Read, Update, Delete (CRUD) - создание, чтение, обновление и удаление объектов данной модели.

Часто данные - самая важная часть приложения. Поэтому будет полезно изолировать данные и методы взаимодействия с ними. Более того, определив интерфейс для работы с моделью, будет полезно его придерживаться, дабы реже менять модель. Вместо этого стоит определить интерфейсы для взаимодействия с моделью. И подстраивать уже контроллер под модель.

Также, определив модель для какого-то типа данных, можно использовать её для многих задач, во многих контроллерах. Таким образом мы можем переиспользовать код модели множество раз.

Опять же, имея единую точку для взаимодействия с базой данных - модель, мы можем на этом "мосту" установить "стражников" - валидацию сохраняемых данных. Это также поможет сохранить наши данные в целостности и нужном формате.

Если же мы говорим о пользовательском интерфейсе, то нам нужно сразу ожидать, что он должен быть гибким, часто меняться и вообще во многом состоять из компромиссов и сомнительных решений. Так что лучше выделить под это дело отдельный "испытательный полигон" - слой представления.

Слой представления отвечает за получение информации от пользователя. А значит здесь будет и первичная валидация и очистка данных, чтобы привести их к виду, в котором наша программа уже будет готова работать с ними. Поэтому тут скорее всего расположатся различные декодеры, парсеры данных, процессоры форм, троттлинг-системы, csrf-проверки и прочие "стражи", охраняющие нас от зловредов снаружи.

В другую же сторону слой представления отдаёт данные пользователю. И в плане преобразования вида данных из внешних во внутренние и наоборот он не сильно отличается от процесса приёма данных - здесь уже будут кодеры в целевой формат, упаковщики данных, генераторы форм, HTML-шаблонизаторы и т.д. Также здесь могут стоять модули для сжимающего кодирования, оптимизации изображений/видео, кеши ответов.

И снова - разные представления могут пользоваться разными моделями данных, более того - во время жизни проекта эти связи (через контроллер) не редко меняются. Поэтому, если мы хотим реже переписывать весь проект - лучше писать модульно, чтобы при изменении требований было нужно переписать только модуль, или же просто немного подправить его интерфейс.

Представьте, что наше приложение изначально было написано для настольных компьютеров с ОС Windows. Позднее мы решили, что выгоднее сделать web-версию. Если наш код был написан монолитом, то весь код придётся переписывать. Если же мы отделили представление данных от логики работы с данными и хранения данных, то можно будет переписать лишь ту часть, что отвечала за представление, то есть интерфейс для пользователя.

Контроллеры же - связующее звено - они принимают очищенную и преобразованную информацию от пользователя и принимают решение, что же стоит делать. В своей работе они имеют доступ к моделям, в которых будет отражен результат работы контроллеров, либо из них контроллер будет брать данные для выполнения задач, полученных от пользователя.

По хорошему, контроллеры - это связующее звено - "клей" между представлениями и моделями. Так как одна модель может использоваться для многих представлений, а одно представление может использовать сразу несколько моделей, нам нужен данный "клей" для их связи. В некотором смысле - это как в реляционных базах данных - таблица для связи многие-ко-многим.

В некоторых реализациях контроллеры - это обычные функции. В других же - набор функций, объединённых одной предметной областью, например, контроллер для регистрации, или же для галереи изображений. Если у нас класс-контроллер, в котором методы занимаются обработкой различных запросов пользователя (отобразить страницу регистрации, регистрация через форму, регистрация по приглашению и т.д.), то методы также называются action-ми (действия).

Толстые модели и простые контроллеры

Частая ошибка новичка - попытаться положить в контроллер всю логику приложения. Часто лучше логику модификации данных держать в модели. Пусть модели будут большими (толстыми), а контроллеры только клеем. Тогда при изменении связей (создании другого контроллера) в другом месте также будет доступно то преобразование модели.

Отговоркой может быть то, что обновление данных может происходить не только в одной модели. Казалось бы, раз контроллер у нас рулит моделями - пусть он этим и занимается. Однако, подобные изменения часто связаны с тем, что сами модели взаимосвязаны. В целом, то что мы назвали модели слоем, не значит, что он "плоский". Часто существуют основные модели и вспомогательные, например, пользователи и их права доступа - права доступа не имеют смысла без пользователей. Очевидно, что пользователи - главная модель, а их права вторичная. Поэтому лучше, чтобы модель пользователя управляла правами, а не контроллер. Иначе у нас будет размазана логика по разным местам, хотя действия будут схожими.

Почти во всех ситуациях лучше держать контроллеры максимально простыми. Есть даже анти-паттерн: Толстые Тупые Уродливые Контроллеры (ТТУК). Попытка уместить логику в контроллер приводит к тому, что контроллеры, отвечающие за разные пользовательские действия будут содержать логику для работы с разными моделями в одном месте. При таком подходе модели и контроллеры слишком сильно связываются, теряется модульность.

Если ещё при этом программист в представлении будет держать только шаблонизатор/кодировщик данных, а валидацию делать в контроллере - получаем вырождение шаблона MVC в обычный монолит с шаблонизатором и адаптером к базе данных. Такой код будет сложно изменить под новые требования (а они всегда есть, если ваш проект жив).

Также может быть вам интересно:

Что есть мотивация? Зачем мотивация тебе?

Говоря о руководстве командой разработчиков, сложно не впасть в эту старую как мир западню - мотивацию. Давайте сегодня постараемся понять: что есть реальная мотивация и как она помогает?

Читать »

Настройка журналирования (логирования) в Python с примерами

Во время работы программы часто нужно сохранять некоторые важные записи о процессе выполнения команды. В Python есть довольно мощный модуль для работы с логами - давайте разберёмся с тем, как его использовать.

Читать »
Фото Как настроить отправку почты из Django

Как настроить отправку почты из Django

Письма об ошибках, отчёты на почту, восстановление паролей - всё это полезно при работе с сайтом. Django предоставляет удобный способ это сделать с минимумом настроек!

Фото Добавляем поддержку медиа-файлов в Django проект

Добавляем поддержку медиа-файлов в Django проект

Современные сайты редко ограничиваются только текстом и вёрсткой. Часто в заметках красуются фотографии, а рядом с описанием товаров - их изображения.

Фото Настройка журналирования (логирования) в Python с примерами

Настройка журналирования (логирования) в Python с примерами

Во время работы программы часто нужно сохранять некоторые важные записи о процессе выполнения команды. В Python есть довольно мощный модуль для работы с логами - давайте разберёмся с тем, как его использовать.

Фото Маленькая книга о Go (golang)

Маленькая книга о Go (golang)

Маленькая книга о Go распространяется под лицензией Attribution-NonCommercial-ShareAlike 4.0 International license. Вы не должны платить за эту книгу.

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django - своя регистрация на сайте

Если вашим сайтом должны активно пользоваться несколько человек, то полезно их различать, а значит - надо уметь создавать пользователей, либо предоставлять возможность регистрации Django пользователей.

Фото Пользователи и авторизация (логин) в Django, кастомизация пользователя

Пользователи и авторизация (логин) в Django, кастомизация пользователя

В Django есть множество встроенных возможностей, которые позволяют не реализовывать многие классы для стандартных операций. Среди них - авторизация. Django изначально предоставляет пользовательскую систему. Но её можно использовать лучше, чем по умолчанию.

Фото Панель администрирования Django - настройка вида (шаблона)

Панель администрирования Django - настройка вида (шаблона)

Простой способ подключить админку к сайту на Django, как сконфигурировать адмиин-панель, как изменить оформление администрационной панели Django фреймворка.

Фото Панель администрирования Django - подключение, настройка, поиск, фильтрация

Панель администрирования Django - подключение, настройка, поиск, фильтрация

Простой способ подключить админку к сайту на Django, как сконфигурировать адмиин-панель и добавить функциональность поиска, массовых действий, как изменить оформление администраторской панели Django фреймворка.