Думаю, ни для кого не секрет, что в разговорах опытных Python-разработчиков, да и не только, часто проскакивают фразы о том, что Django — зло, что у Django плохая архитектура и на нем невозможно без боли написать большой проект. Даже средний проект Django зачастую сложно поддерживать и расширять.
Предлагаю разобраться, почему так происходит и что не так с Django-проектами.
Немного теории
Когда мы начинаем изучать Django без опыта работы с другими языками и фреймворками, помимо документации мы читаем туториалы, статьи, книги и почти в каждой видим что-то вроде этого:Django — это платформа, использующая шаблон проектирования Модель-Представление-Контроллер (MVC).А еще есть куча неточных диаграмм и пояснений о том, что такое MVC. Почему они неточны и что с ними не так, вы можете увидеть Здесь или Здесь .
Обычно в таких схемах MVC описывается так:
- Модель - доступ к хранилищу данных
- Представление — это интерфейс, с которым взаимодействует пользователь.
- Контроллер — это своего рода связующий объект между моделью и представлением.
Стоит обратить внимание на две вещи.
Во-первых, M в MVC часто означает модель данных, и говорят, что это некий класс, который отвечает за предоставление доступа к базе данных.
Что неверно и не соответствует классическому MVC и его потомкам MV*.
В классическом MVC M означает модель предметной области — объектная модель предметной области, объединяющая данные и поведение.
Точнее, M в MVC — это интерфейс к модели предметной области, поскольку модель предметной области — это слой объектов, описывающий различные аспекты определенной области бизнеса.
Где одни объекты предназначены для моделирования элементов данных, которые работают в этой области, а другие должны формализовать определенные бизнес-правила.
Во-вторых, в Django нет выделенного слоя контроллера, и когда вам говорят, что в Django слой представлений является контроллером, не верьте этим людям.
Обратитесь к официальной документации, а точнее к Часто задаваемые вопросы , то вы можете видеть, что этот слой соответствует принципам уровня представления в MVC, особенно если мы рассматриваем DRF, а слоя контроллера как такового в Django нет. Как указано в FAQ, если вам действительно нужны аббревиатуры, вы можете использовать аббревиатуру MTV (модель, шаблон и представление) в контексте Django. Если вы действительно хотите рассмотреть Web MVC и сравнить Django с другими фреймворками, то для простоты вы можете считать его контроллером представления.
Несмотря на то, что Django не соответствует аббревиатуре MVC, он реализует основную идею MVC — отделение бизнес-логики от логики представления данных.
Но на практике это не всегда так по ряду причин, о которых мы поговорим ниже.
Перейдем к практике
Выделим несколько слоев в приложениях Django, которые есть в каждом туториале и практически в каждом проекте:- интерфейс/шаблоны
- сериализаторы/формы
- Просмотры
- модели
В основном мы будем рассматривать Django с использованием DRF. Попробуем на двух простых примерах проанализировать, что должно быть размещено в каждом слое и какую ответственность несет каждый слой.
Первый случай — создание заказа.
При создании заказа нам необходимо:
- проверить актуальность заказа и наличие товара
- создать заказ
- резервировать товар на складе
- отправьте заявку менеджеру
- уведомить пользователя о том, что его заказ обработан
Здесь все просто, нам нужно показать пользователю список его заказов:
- получить список заказов пользователей
Уровень сериализаторов/форм
Слой сериализаторов имеет три основные функции (все выводы для сериализаторов справедливы и для форм):- проверить данные
- преобразовать данные запроса в типы данных Python
- конвертировать сложные объекты Python в простые типы данных Python (например, модели Django в dict)
Пример использования из документации:
Теги: #python #архитектура #djangoclass CommentSerializer(serializers.Serializer):
-
Когда Это Будет - Анонсы Будущих Событий
19 Oct, 24 -
Покупка Github Завершена. Что Будет Дальше?
19 Oct, 24 -
Официальное Открытие Bitbybit
19 Oct, 24 -
83% Интернет-Пользователей «Кибербольны»
19 Oct, 24
