λ
Кирилл возьми котовей транзактор и сделай прост 3 метода лул
Size: a a a
2020 August 28
Oℕ
Наверное, можно складывать аргументы в кейсклассы
Oℕ
А потом делать апдейты полиморфными и требовать линзы\экстракты на свой набор аргументов
λ
Линзы из тофу. Переносим в другой чят
Б
ущерб читаемости
KS
Стоп-стоп, какие линзы.
Oℕ
ущерб читаемости
(сам таким иногда страдаю)
Oℕ
Подожди Кирилл, щас мы без скасти до рексхем дойдём
ND
VS
Написано же, что это инъекция
:( так хотел пошутить, что сигнатуру не дочитал
VS
Kirill Shelopugin
Дуби-челы. Допустим, у меня есть N разных независимых сущностей, которые в бизнес-логике надо обновлять. Прямо
update1 >> update2 >> update3 и так далее. Хочу это делать в одной транзакции. Логичнее всего инкапсулировать ConnectionIO, их композицию и запуск в отдельном модуле (классе) и из бизнес-логики вызывать именно его. Но для апдейта сущностей нужны разные аргументы, совсем. В результате api этого репозитория будет выглядеть ужасно с миллионом аргументов - часть аргументов для апдейта сущности 1, часть для сущности 2 и так далее. Как вы живете с таким?сделай инстансы репозиториев в F = ConnectionIO и используй их где нужно
VS
а для рабоче крестьянских сервисов пусть будут в норм IO
w
λ
сделай инстансы репозиториев в F = ConnectionIO и используй их где нужно
И в месте композиции ему нужно будет передать параметры все
λ
Ну да, тут вопрос вообще не про дуби
KS
Да, я просто когда с дуби возился, на такое наткнулся, так что дуби тут просто как пример
λ
А просто про то, как передать много параметров снаружи в нижележайщий слой
KS
Какие есть варианты, кроме кейс-классов и HasContext с субконтекстом?