Обсудили немного в личке, dishka в норме предлагает делать интеграции с фреймворкам, чтобы просто маркировать зависимости через FromDishka, а библиотека сама оборачивала в контекст и прокидывала конетйнер без использования глобальных переменных. Это можно попробовать реализовать и для django, но надо вникать в корнер кейсы, особенно в сочетании с DRF. Путь звучит понятно, но его должен кто-то пройти, встроенной интеграции мы пока не подготовили.
При этом dishka не запрещает использовать его в стиле как было сделано с punq. Из-за явного контроля scope это увеличивает количество строк с 1 до 2
class BuyProductView(APIView):
permission_classes = (CustomerRequired,)
def post(self, request: Request) -> Response:
serializer = BuyProductSerializer(data=request.data)
serializer.is_valid(raise_exception=True)
with container() as c:
service = c.get(BuyProductService)
result = service(product=serializer.validated_data, customer=request.user.customer)
return Response(
data=result.asdict(),
status=status.HTTP_200_OK,
)
В качестве бонуса такого решения - мы получаем возможность использовать финализацию ресурсов, которые использовались внутри service (в том числе косвенно) или делать несколько раз get, переиспользуя созданные объекты.
Так же коллеги предлагали положить контейнер в request объект, тогда можно избавить от глобальной переменной. А вход в скоуп монжо сделать в middleware, но это обсуждаемо.
Ну что ж. Я автор. Я говорил обычно что-то другое. Скорее всего "зачем вам DI, если у вас джанга". Так что я тут скорее заинтересован в вашем мнении, почему же не подходит?
На самом деле, хотелось бы услышать побольше про выбор контейнеров, с чем сравнивали, почему не подошли? Я соглашусь, что большинство их в питоне очень низкого качества, но у вас наверно своё мнение есть. В частности, у меня есть свой проект - dishka, который решает, например, задачу контроля скоупов. Рассматривали ли вы его?
2) Думаю, речь не про уровень аппки, а про то чтобы контейнер создавался при старте и передавался во вьюхи. Чтобы его можно было, в частности, в тестах подменить
4) все ещё не понимаю зачем вы передаете данные при резолвинге сервиса. Ну передайте вы при вызове его методов, предвариательно заложив в интерфейс. Если же это конфигурационные параметры - передавайте при настройке контейнера, а не во вьюхе опять же
Не раскрыта тема внедрения зависимостей. Ваш сервис по факту ни от чего не зависит - ни от адаптера для доступа к БД, ни от вспомогательных объектов, реализующих БЛ. Вместо этого почему-то он принимает продукт в init, а не как данные. Это немного странно
С другой стороны, у вас есть глобальный контейнер. Вы его используете напрямую, а не получаете сервисо во вьюхе.
Суммарно, это больше выглядит как паттерн ServiceLocator, а не Dependency Injection.
Что же касается самого punq, меня в нем в своё время остановила одна вещь - отсутствие явных скоупов. Вы не можете ему сказать, что всё время пока вы обращаетесь к контейнеру внутри обработчика запроса надо возвращать один и тот же экземпляр конкретного класса, а при выходе - почистить (иногда вызвав доп функции финализации).
А подскажите, какова цель вашего проекта? Чтобы работу находили неквалифицированные люди или что? Проводите ли вы собеседование кандидата прежде чем дать ему доступ к вашему боту?
Валидация имеет несколько форм. Во-первых валидация по форме. Данные некорректных типов просто не должны попадать в бизнес логику. Эту часть делают на этапе парсинга запроса, тут хорошо справляется пидантик
Во-вторых это валидация бизнес правил. Часть из них ограничены сущностью, часть связаны с иерархией сущностей, часть включают в себя несколько сущностей задействованных в одной операции, а часть вообще распространяются на всю систему. Эти правила силами пидантика делать часто просто невозможно.
Плохая часть пидантика заключается в том, что он смешивает валидацию и парсинг. Это нормально для DTO и первого варианта валидаций, но может иногда стрелять при попытке использования в БЛ.
К тому же домен хочется быть стабильным. Пидантик второй версии ещё слишком молод чтобы претендовать на это
Самое неприятное когда выясняется что задача и не может быть решена на 100% в том виде как ее решила нейросеть. Что именно этот 1% требует вообще менять подход
Обычный Enum — штука классная, но строгая. Если ты создашь OrderStatus.PENDING = 1, а потом попробуешь сравнить его просто с числом (if status == 1), Python скажет: «Э, нет, это разные вещи!». Для него объект перечисления не равен числу, даже если внутри него спрятана единица.
Но в реальности мы часто получаем данные из баз данных или через API в виде обычных чисел. И тут на сцену выходит IntEnum.
И правильно питон скажет. При получении из апи вы должны провалидировать данные и сконвертировать в ваш энум, а не забивать на смысл энума разрешая его использовать вместе с интом. Энум обычно предполагает совершенно другие сценарии использования чем обычный int. И если где-то вам надо конвертировать одно в другое - там по месту и конвертируйте
Как вы собираетесь без правильный абстракций смотреть только в одном место? Нет, если у вас не выстроены абстракции и границы между модулями, вам придется прочитать все и держать все в голове, чтобы быть в состоянии вносить изменения, ведь связано может быть что угодно с чем угодно
Валидация значений вполне себе задача бизнес логики. Тут вам и паттерн ValueObject и методы изменения с проверками инвариантов. Только для этого пидантик не нужен, тем более что он ещё внедряет свои неявные преобразования алиасов и типов.
Доменный уровень действительно не должен зависеть от транспорта, но никто не запрещает использовать там вспомогательные инутрменты, если они достаточно надежные и стабильные. Проблема тут в том, что pydatic модели очень хочется сразу настроить на транспорт, потому что они это могут и будет очень сложно отговаривать коллег каждый раз.
Если у вас калькулятор на brainfuck, почему большая часть вычислений написна на питоне?
Обсудили немного в личке,
dishkaв норме предлагает делать интеграции с фреймворкам, чтобы просто маркировать зависимости черезFromDishka, а библиотека сама оборачивала в контекст и прокидывала конетйнер без использования глобальных переменных. Это можно попробовать реализовать и для django, но надо вникать в корнер кейсы, особенно в сочетании с DRF. Путь звучит понятно, но его должен кто-то пройти, встроенной интеграции мы пока не подготовили.При этом
dishkaне запрещает использовать его в стиле как было сделано сpunq. Из-за явного контроля scope это увеличивает количество строк с 1 до 2В качестве бонуса такого решения - мы получаем возможность использовать финализацию ресурсов, которые использовались внутри service (в том числе косвенно) или делать несколько раз
get, переиспользуя созданные объекты.Так же коллеги предлагали положить контейнер в request объект, тогда можно избавить от глобальной переменной. А вход в скоуп монжо сделать в middleware, но это обсуждаемо.
Не забываем что в джаве нет функций
Ну что ж. Я автор. Я говорил обычно что-то другое. Скорее всего "зачем вам DI, если у вас джанга". Так что я тут скорее заинтересован в вашем мнении, почему же не подходит?
На самом деле, хотелось бы услышать побольше про выбор контейнеров, с чем сравнивали, почему не подошли? Я соглашусь, что большинство их в питоне очень низкого качества, но у вас наверно своё мнение есть. В частности, у меня есть свой проект - dishka, который решает, например, задачу контроля скоупов. Рассматривали ли вы его?
2) Думаю, речь не про уровень аппки, а про то чтобы контейнер создавался при старте и передавался во вьюхи. Чтобы его можно было, в частности, в тестах подменить
4) все ещё не понимаю зачем вы передаете данные при резолвинге сервиса. Ну передайте вы при вызове его методов, предвариательно заложив в интерфейс. Если же это конфигурационные параметры - передавайте при настройке контейнера, а не во вьюхе опять же
Не раскрыта тема внедрения зависимостей. Ваш сервис по факту ни от чего не зависит - ни от адаптера для доступа к БД, ни от вспомогательных объектов, реализующих БЛ. Вместо этого почему-то он принимает продукт в init, а не как данные. Это немного странно
С другой стороны, у вас есть глобальный контейнер. Вы его используете напрямую, а не получаете сервисо во вьюхе.
Суммарно, это больше выглядит как паттерн ServiceLocator, а не Dependency Injection.
Что же касается самого punq, меня в нем в своё время остановила одна вещь - отсутствие явных скоупов. Вы не можете ему сказать, что всё время пока вы обращаетесь к контейнеру внутри обработчика запроса надо возвращать один и тот же экземпляр конкретного класса, а при выходе - почистить (иногда вызвав доп функции финализации).
А подскажите, какова цель вашего проекта? Чтобы работу находили неквалифицированные люди или что? Проводите ли вы собеседование кандидата прежде чем дать ему доступ к вашему боту?
Валидация имеет несколько форм. Во-первых валидация по форме. Данные некорректных типов просто не должны попадать в бизнес логику. Эту часть делают на этапе парсинга запроса, тут хорошо справляется пидантик
Во-вторых это валидация бизнес правил. Часть из них ограничены сущностью, часть связаны с иерархией сущностей, часть включают в себя несколько сущностей задействованных в одной операции, а часть вообще распространяются на всю систему. Эти правила силами пидантика делать часто просто невозможно.
Плохая часть пидантика заключается в том, что он смешивает валидацию и парсинг. Это нормально для DTO и первого варианта валидаций, но может иногда стрелять при попытке использования в БЛ.
К тому же домен хочется быть стабильным. Пидантик второй версии ещё слишком молод чтобы претендовать на это
Ну я пару раз брался за ИИ. Сначала удивлялся как элегантно выглядело его решение, а потом понимал что принесли в жертву - важные корнеркейсы
Самое неприятное когда выясняется что задача и не может быть решена на 100% в том виде как ее решила нейросеть. Что именно этот 1% требует вообще менять подход
И правильно питон скажет. При получении из апи вы должны провалидировать данные и сконвертировать в ваш энум, а не забивать на смысл энума разрешая его использовать вместе с интом. Энум обычно предполагает совершенно другие сценарии использования чем обычный int. И если где-то вам надо конвертировать одно в другое - там по месту и конвертируйте
Автор каждые несколько дней выдает очередной опус, маловероятно что он сам это пишет
Как вы собираетесь без правильный абстракций смотреть только в одном место? Нет, если у вас не выстроены абстракции и границы между модулями, вам придется прочитать все и держать все в голове, чтобы быть в состоянии вносить изменения, ведь связано может быть что угодно с чем угодно
Меня тоже это триггернуло. Но при этом я отдаю себе отчёт, что никакой вывод только на основании этой информации я сделал не могу.
Хуже, при внимательном рассмотрении здравый смысл оказывается просто когнитивными искажениями.
Там есть второе опасное место - дублирование ORM моделей и моделей бл. Если вы так делаете, у вас будут проблемы с idm и UoW алхимии.
Я не уверен. Там каша и большую часть делает все равно starlette.
как насчет этой? https://habr.com/ru/companies/pt/articles/820171
Валидация значений вполне себе задача бизнес логики. Тут вам и паттерн ValueObject и методы изменения с проверками инвариантов. Только для этого пидантик не нужен, тем более что он ещё внедряет свои неявные преобразования алиасов и типов.
Доменный уровень действительно не должен зависеть от транспорта, но никто не запрещает использовать там вспомогательные инутрменты, если они достаточно надежные и стабильные. Проблема тут в том, что pydatic модели очень хочется сразу настроить на транспорт, потому что они это могут и будет очень сложно отговаривать коллег каждый раз.