Урок 3 | Аутентикация и Авторизация в FastAPI [часть 1] | Intermediate ⭐ | Python на практике

[@andynaz7044]

класс!

[@python-practice]

Спасибо! Рад, что понравилось.

[@DEVJCactus]

Вроде понятно все) Пойду пробовать)))) Только одно глаза режет, почему у тебя контроллер это представление? Репозиторий этр менеджер?

[@python-practice]

Привет, спасибо за комментарий и хороший вопрос! На данном этапе я стараюсь больше посвятить внимание Python, а вопросы архитектуры и инфраструктуры буду раскрывать в следующих уроках. Итак, относительно вопросов: Почему репозиторий - это менеджер? UserManager в нашем случае управляет данными пользователей в оперативной памяти и не взаимодействует с базой данных (условно выполняет роль базы данных). Это не полноценный репозиторий в терминах DDD, а скорее упрощённая абстракция для демонстрации идеи. В уроке, который я запланировал под названием "Паттерн Репозиторий в FastAPI", я заменю UserManager на SQLAlchemy (с использованием PostgreSQL) и добавлю полноценный слой репозитория. Урок также будет посвящён тому, как репозиторий помогает разделить бизнес-логику и взаимодействие с БД. В более сложной архитектуре я использую такую цепочку: БД request -> endpoint -> dto -> service -> dto -> repository -> orm -> db Для других стораджей: request -> endpoint -> dto -> service -> dto -> repository -> library -> storage С кастомной реализацией: request -> endpoint -> dto -> service -> dto -> repository -> adapter -> storage Для простых случаев: request -> endpoint -> service -> orm -> db Через несколько уроков я планирую ввести такие элементы, как: Service (сервисы для бизнес-логики) DTO (объекты для передачи данных) Repository (слой для работы с данными) ORM (например, SQLAlchemy для взаимодействия с БД). Адаптер - собственный слой, который адаптирует сторонний API (библиотеку) к интерфейсу приложения Почему контроллер - это представление? Например, /login - это эндпоинт (контроллер в FastAPI, а не чистый вью в классическом смысле), который обрабатывает HTTP-запросы. В моём примере он вызывает UserService для проверки данных пользователя и создания токенов. Сам эндпоинт не содержит бизнес-логики - он выполняет роль "посредника" между запросом и сервисами. Если тебе интересно углубиться в эту тему, рекомендую статью: medium.com/@jeremyalvax/fastapi-backend-architecture-model-controller-service-44e920567699

[@DEVJCactus]

@@python-practice кстати, вот ты упомянул DDD. И мне сразу же вспомнилась книжка про TDD Кента Бека. И собственно говоря, предлагаю сделать серию видео роликов по разработке с применением методики TDD.

[@python-practice]

Спасибо за предложение! окей, сделаем чуть позже

[@python-practice]

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