Обновить

Комментарии 4

Раньше (например, во Flask) вам пришлось бы внутри функции писать int(task_id), оборачивать это в try/except, чтобы поймать ошибку ValueError, если какой-то умник вместо числа передаст буквы.

Во Flask есть конверторы. Так функция с декоратором @app.route('<int:id>') просто не будет обрабатывать запросы по адресам, которые нельзя преобразовать в числа. Если для таких нет другой функции, то Not Found.

 db: Session = Depends(get_db)

Дальше 'сеньора' не читал, не надо так делать, даже не вздумайте.

Во первых вы нарушите таким образом слои архитектуры, во вторых есть IoC контейнеры...

Подскажите пожалуйста, а почему не стоит использовать такую конструкцию?
Чем это грозит?
Если использовать паттерн репозиторий
def get_repo_users( session: AsyncSession = Depends(get_db)):
return UserRepository(session=session)

@app.get("/{user_id}")
async def get_user(user_id: int, user_repo:UserRepository = Depends(get_repo_users)):
found_user = await user_repo.get(user_id)

тот же самый репозиторий, можно передать в UseCase или другой доменный слой, где с ним уже будет работать бизнес логика

такой вариант будет являться антипатерном?

Жаль, что ни в статье, ни в программе курса нет ни слова о тестировании. Для сознательных новичков было бы в самый раз.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации