Любая технология не лишена недостатков.

Django. Упрощает ли фреймворк жизнь

Затрагиваем нюансы разработки на крупных фреймворках.

Основное преимущество Django — достойная встроенная ORM, качественная админ-панель и неплохой уровень абстракций и дополнительных библиотек, снижающих потребности в написании велосипедов.

Когда мы говорим о разработке классического CRUD-приложения, использование мощного фреймворка существенно экономит время на разработку. Ракету можно запустить в космос за пару часов.

Определенные сложности начинаются на этапе усложнения задач и разрастания кодовой базы.

Затронем буквально несколько примеров, когда работа внутри фреймворка перестает быть легким плаванием.

Авторизация

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

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

Вспомнит ли сходу каждый django-разработчик, зачем внутри используется импорт ugettext_lazy?

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

Формы

Работа с формами в Django — отдельная история. В Ruby On Rails форм, как полностью самостоятельной логики — нет. И это кажется вполне уместным, потому что основное можно реализовать на стороне представлений.

В Django предоставляется возможность работы, как на стороне представлений, так и на стороне форм. И там, и там предоставляется множество классов и методов, которых желательно придерживаться, не уходя в написание глубоких велосипедов.

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

И собственно это приводит к главной особенности Django…

Масса всего при отсутствии единых паттернов

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

Условно, одни выстраивают бизнес логику с завязкой на стороне Models, другие — на стороне View. И такие вилки — на каждом шаге работы с фреймворком.

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


Если остались вопросы

Свяжемся с вами вотсап.