A
Каким образом он его добавит чтобы не мешать логику все равно запрос надо делать через репозиторий или на прямую бд косвенно мешается все
Size: a a a
2021 September 27
AK
Онлайн-курсы, но как мне кажется, на некоторые оффлайн-мероприятия идут не пойми кто. А ведь если например посмотреть ценник на некоторые оффлайн-мероприятия, то он даст прикурить разным там курсам.
VL
твоя блл не будет ничего знать про транзакции и просто будет вызывать методы репо
репо тож в обычном режиме
магия добавится когда обернешь в декоратор
посмотри как делаяют в спрингах или в доке тайпорм
репо тож в обычном режиме
магия добавится когда обернешь в декоратор
посмотри как делаяют в спрингах или в доке тайпорм
AK
Так что я могу только приветствовать начинания Ильи Климова. Люди деньги платят, чтобы или их код, или их проекты эксперты разбирали, а тут все даром, бери и пользуйся, Владилен должен бы быть благодарен за такой разбор.
VL
так а ДИ тут причем
VL
не, метод в котором транзакция происходит, уровень сервисов а не ДМ
A
Из этого знаем что сервиса надо знать как РЕПО может открыть и закрыть транзакцию
VL
https://orkhan.gitbook.io/typeorm/docs/transactions#transaction-decorators
просто перекинуть декоратор из сервиса на уровень выше ( хотя в сервисе можно оставить если в нем нет блл и она вся в ДМ и сервис выступает условным контррллером)
просто перекинуть декоратор из сервиса на уровень выше ( хотя в сервисе можно оставить если в нем нет блл и она вся в ДМ и сервис выступает условным контррллером)
VL
я про шаблон говорю, не про @Decorator
VL
но повторюсь, если сервис не содержит логики и она вся в ДМ, то можно прям в сервисе ебнуть
r
Зачем вы тэгнули арабского пользователя...
АП
Ну назови shashechki
А ты можешь сформулировать минусы того, что бл начнёт хранить информацию о транзакциях? Например о том, что в операции А транзакция нужна, а в Б не нужна
А ты можешь сформулировать минусы того, что бл начнёт хранить информацию о транзакциях? Например о том, что в операции А транзакция нужна, а в Б не нужна
A
это отлично!
и про выбор ментора добавьте. там был вопрос на прошлой неделе
и про выбор ментора добавьте. там был вопрос на прошлой неделе
VL
Простой вариант
Убери логику из сервисов и перенеси ее в ДМ :)
Но офк в идеальном мире блл не должен знать про транзакции, через декоратор сработает решение
Убери логику из сервисов и перенеси ее в ДМ :)
Но офк в идеальном мире блл не должен знать про транзакции, через декоратор сработает решение
VL
транзакции будут в сервисе у которого нема (или почти) логики, что не нарушает идею про разделение инфры и логики
так же намного удобнее тестировать ибо если мы тестируем логику то это ЮТ на дм, а сервисы через ИТ кроем и кайфуем
так же намного удобнее тестировать ибо если мы тестируем логику то это ЮТ на дм, а сервисы через ИТ кроем и кайфуем
VL
>ДМ слой может оперировать сразу несколькими сущностями
а че нет то, вон шаблон аггрегат тебе
>я думал что сервисы их собирают и оркестрируют
все верно
а че нет то, вон шаблон аггрегат тебе
>я думал что сервисы их собирают и оркестрируют
все верно
DL
Можешь тут глянуть.
https://khalilstemmler.com/articles/typescript-domain-driven-design/repository-dto-mapper/#Repositories
Идея в том что транзакция не выходит за границу aggregation root а репозиторий как раз работает с ним
https://khalilstemmler.com/articles/typescript-domain-driven-design/repository-dto-mapper/#Repositories
Идея в том что транзакция не выходит за границу aggregation root а репозиторий как раз работает с ним
MZ
Народ
Такой вопрос
Есть сервер
На него приходят 5 пост запросов в течении некоторого времени ( объекты )
Как можно собрать данные с этих запросов ?
Такой вопрос
Есть сервер
На него приходят 5 пост запросов в течении некоторого времени ( объекты )
Как можно собрать данные с этих запросов ?