Принципы проектирования фреймворка Django

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

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

Принцип "Не повторяйся" (DRY)
Повторение может быть полезно, чтобы подчеркнуть суть, но когда речь идет о веб-разработке, это приводит к дополнительной и трудоемкой работе. На самом деле, сама природа веб-разработки, которая оперирует несколькими уровнями, взаимодействующими друг с другом (например, шаблоны HTML, методы бизнес-логики и базы данных), склонна к повторениям.  Фреймворк Django действительно пытается заставить вас не повторяться, поэтому давайте посмотрим, как Django заставляет вас не повторяться и почему это хорошо.

Допустим, вы хотите создать приложение для кофейни, которое будет публиковать информацию о магазинах, а также иметь контактную форму для клиентов. Первое, что вам нужно будет сделать, это определить, какая информация требуется для магазинов и контактной формы. На рисунке показан макет двух моделей Django для каждой из этих сущностей:

Обратите внимание, что модели Django на рисунке имеют разные имена полей и тип данных для ограничения значений. Например, утверждение name = models.CharField(max_length=30) говорит Django, что название магазина должно содержать максимум 30 символов, а утверждение email = models.EmailField() говорит Django, что контактная сущность должна содержать действительное значение email. Если кофейня похожа на большинство веб-приложений, вы обычно делаете следующее для сущностей магазина и контактов:

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

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

Не проще ли было бы на основе утверждения типа models.CharField(max_length=30) сгенерировать ввод HTML-формы, утверждение SQL и автоматически подтвердить, что информация содержит только 30 символов? Именно это и делает принцип DRY проектирования Django.

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

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

Хотя пока еще немного преждевременно обсуждать реальные методы генерации таких конструкций из моделей Django, не стоит говорить, что это намного проще, чем отслеживать множество ссылок на одно и то же (например, имя, email) в HTML-формах, SQL, логике валидации и других местах.

В этом смысле Django действительно помогает вам определять вещи в одном месте и не повторять их в других местах. Обратите внимание, что всегда есть возможность повторить себя для получения пользовательского поведения, но по умолчанию Django применяет принципы DRY почти во всем, что вы с ним делаете.

Свободно связанная архитектура

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

Свободно связанная архитектура означает отсутствие жестких зависимостей между компонентами, составляющими приложение Django. Например, в Django вполне допустимо обслуживать контент непосредственно из HTML-шаблона, без необходимости использовать бизнес-логику или настраивать базу данных. Точно так же в Django вполне допустимо отказаться от использования HTML-шаблона и возвращать необработанные данные непосредственно из метода бизнес-логики (например, для REST-сервиса).