В статье код как-будто бы из алхимии < 1.4, уже на 1.4 session.query считалось устаревшим, а с 2.0 это уже deprecated подход(конструкцию не удалили, но внутри она теперь работает так же как sqlalchemy.select)
Когда увидел заголовок статьи, подумал что наконец-то увижу как люди пишут свой UoW для core алхимии, но оказалось что опять собрали все репозитории в одном место и добавили .commit и .rollback. Имхо, если нужен такой интерфейс, то хотя бы репозитории надо из него удалить, нет же проблем прокинуть одну и ту же сессию в разные репозитории.
А DI в FastAPI есть, но, насколько мне известно, только как раз таки на уровне контроллера. Я почти уверен, что можно что-то придумать со сторонними либами для DI. Так что чтобы получить DI на уровне бизнес логики, тебе ещё нужно докрутить логики и нести доп. зависимости в проект. Не минус, но такое есть. Либо ленишься один раз написать DI и кайфовать, либо дедовским методам прокидываешь по слоям абстракции
Почитайте что такое DI и как правильно его использовать. Скорее всего вы путаете DI с Service Locator(DI vs Service Locator) Зачем нужен "DI в бизнес-логике", если эту бизнес-логику вызывает контроллер, в котором и собираются(используются собранные) зависимости? Представим обычный флоу в архитектуре Порты и Адаптеры
Main -> Controller -> Service Layer -> Data Layer 1. Main - всё что связано с инициализацией проекта. Например в нашем случае это инстанс FastAPI, engine алхимии, etc. Так же здесь собираются все зависимости(Репозитории для Data Layer, Инстансы сервисов для Service Layer(будь это отдельный класс для отдельного интерактора в рамках юзкейса или один большой класс, где каждый публичный метод это интерактор) 2. Controller - получает зависимость в виде интерактора и вызывает её. 3. Service Layer - вызывает метод репозитория из Data Layer 4. Data Laye - использует зависимость(сессия/engine) которую прокинули при инициализации в 1 пункте
Зачем здесь, например в Service Layer, отдельный какой-то Service Locator, если изначально был резолв зависимости самого Service Layer?
К тому же, советую немного разобраться как работает Depends в FastAPI. Я бы не назвал это нормальным DI, т.к что бы он таковым мог называться, нужно очень много костылять(например у него один глобальный scope). Depends в FastAPI я бы скорее использовал для сбора запроса(query/body параметры и etc.) а для реальных зависимостей использовал более подходящие инструмент. Чего только стоит использование threadpool'а на резолв любой sync зависимости(у тебя 10 Depends, которые внутри просто парсят header/body/etc? Держи 10 потоков. У тебя больше 4 RPS? Пятый запрос будет ждать, пока у всех остальных запросов исполнятся Depends, т.к стоит лимит в 40 тредов). Мы сейчас используем python-dependency-injector, но минусов у него пруд пруди. Сейчас "на хайпе" dishka, т.к активно поддерживается, написан "местным" разработчиком ну и в принципе адекватный продукт(как минимум он не написан на чистом C, как p-d-i)
Причём здесь репозитории и UoW? Кстати о generic репозиториях - why the generic repository is just a lazy anti pattern
В статье код как-будто бы из алхимии < 1.4, уже на 1.4 session.query считалось устаревшим, а с 2.0 это уже deprecated подход(конструкцию не удалили, но внутри она теперь работает так же как sqlalchemy.select)
Когда увидел заголовок статьи, подумал что наконец-то увижу как люди пишут свой UoW для core алхимии, но оказалось что опять собрали все репозитории в одном место и добавили .commit и .rollback. Имхо, если нужен такой интерфейс, то хотя бы репозитории надо из него удалить, нет же проблем прокинуть одну и ту же сессию в разные репозитории.
Почитайте что такое DI и как правильно его использовать. Скорее всего вы путаете DI с Service Locator(DI vs Service Locator)
Зачем нужен "DI в бизнес-логике", если эту бизнес-логику вызывает контроллер, в котором и собираются(используются собранные) зависимости? Представим обычный флоу в архитектуре Порты и Адаптеры
Main -> Controller -> Service Layer -> Data Layer
1. Main - всё что связано с инициализацией проекта. Например в нашем случае это инстанс FastAPI, engine алхимии, etc. Так же здесь собираются все зависимости(Репозитории для Data Layer, Инстансы сервисов для Service Layer(будь это отдельный класс для отдельного интерактора в рамках юзкейса или один большой класс, где каждый публичный метод это интерактор)
2. Controller - получает зависимость в виде интерактора и вызывает её.
3. Service Layer - вызывает метод репозитория из Data Layer
4. Data Laye - использует зависимость(сессия/engine) которую прокинули при инициализации в 1 пункте
Зачем здесь, например в Service Layer, отдельный какой-то Service Locator, если изначально был резолв зависимости самого Service Layer?
К тому же, советую немного разобраться как работает Depends в FastAPI. Я бы не назвал это нормальным DI, т.к что бы он таковым мог называться, нужно очень много костылять(например у него один глобальный scope). Depends в FastAPI я бы скорее использовал для сбора запроса(query/body параметры и etc.) а для реальных зависимостей использовал более подходящие инструмент. Чего только стоит использование threadpool'а на резолв любой sync зависимости(у тебя 10 Depends, которые внутри просто парсят header/body/etc? Держи 10 потоков. У тебя больше 4 RPS? Пятый запрос будет ждать, пока у всех остальных запросов исполнятся Depends, т.к стоит лимит в 40 тредов).
Мы сейчас используем python-dependency-injector, но минусов у него пруд пруди. Сейчас "на хайпе" dishka, т.к активно поддерживается, написан "местным" разработчиком ну и в принципе адекватный продукт(как минимум он не написан на чистом C, как p-d-i)
https://quanttype.net/posts/2023-10-31-do-not-use-requirements.txt.html
TL;DR: requirements.txt это обычный дамп всех зависимостей, нормально контролировать зависимости через него невозможно. Попробуй установить какой-нибудь старый проект. Скорее всего ничего не получится.
(сам https://github.com/huyhoang17/kuzushiji_recognition пытался запустить и куча wheel/cython ошибок, в итоге сам зависимости прописал и запустилось)