TS
Size: a a a
2021 February 02
YZ
Я правильно понимаю, что в таком случае, роутер дергает контроллер, а тот дергает сервисы?
Контролер=роутер->менеджмент->сервис->репозиторий. У нас так
KH
Контролер=роутер->менеджмент->сервис->репозиторий. У нас так
менеджмент это типо usecase?
TS
Но кучу различных апи написаны используя models and controllers
большинство софта написано на антипаттернах
YZ
менеджмент это типо usecase?
Грубо говоря да, необходимость в этом слое появилась чтоб использовать несколько сервисов и не дублировать эту логику в контролерах
VK
большинство софта написано на антипаттернах
Недавно ходил на собес, СТО спросил за mvc, сказал, что не работал с ним, но рассказал за паттерн.
Он мне сказал, если вы не использовали mvc, как же вы без него архитектуру приложения писали?
Он мне сказал, если вы не использовали mvc, как же вы без него архитектуру приложения писали?
KH
Грубо говоря да, необходимость в этом слое появилась чтоб использовать несколько сервисов и не дублировать эту логику в контролерах
в контроллере никакой доменной логики конечно. А валидатор где ставите на контроллере или на юзкейсе? Или и там и там?
YZ
в контроллере никакой доменной логики конечно. А валидатор где ставите на контроллере или на юзкейсе? Или и там и там?
Да. Валидаторы, это да, проблема, мы решили вынести в кастомную мидвалу которая подтягивает модель с правилами.
TS
Недавно ходил на собес, СТО спросил за mvc, сказал, что не работал с ним, но рассказал за паттерн.
Он мне сказал, если вы не использовали mvc, как же вы без него архитектуру приложения писали?
Он мне сказал, если вы не использовали mvc, как же вы без него архитектуру приложения писали?
Передайте ему: Тимур сказал, что он профнепригоден
VK
Передайте ему: Тимур сказал, что он профнепригоден
Хорошо, спасибо)
Та там веселый cto, спрашивает, доя чего нужны промисы и из-за какой проблемы были созадны.
Рассказываю за callback hell, меньше вложеность и прочее, говорит, что промисы херня и ничего не решили, так за все технологии
Та там веселый cto, спрашивает, доя чего нужны промисы и из-за какой проблемы были созадны.
Рассказываю за callback hell, меньше вложеность и прочее, говорит, что промисы херня и ничего не решили, так за все технологии
A
Есть еще очень популярный паттерн - ITS (I tak soydet)
KH
почему про валидатор зашла речь. По хорошему контроллер ничего не знает о бизнес логике, соответственно там нельзя проверять на всякие ограничения, которые навязывает доменная модель. Получается, что контроллер должен смапить свой входной тип на входной тип юзкейса. Часто конечно этого могут не делать, ибо они совпадают. Но в rest так не получится, т. к. часто передаются данные в params и query. А это всегда строки. И получается что нужен валидатор в контроллере - потом маппинг - потом уже валидатор на юзкейсе.
Д
Есть еще очень популярный паттерн - ITS (I tak soydet)
да, часто встречается)
Д
Есть еще очень популярный паттерн - ITS (I tak soydet)
кстати иронично что его описал человек с такой аватаркой XD
МШ
кстати иронично что его описал человек с такой аватаркой XD
Это не просто паттерн, это стиль жизни)))
YZ
почему про валидатор зашла речь. По хорошему контроллер ничего не знает о бизнес логике, соответственно там нельзя проверять на всякие ограничения, которые навязывает доменная модель. Получается, что контроллер должен смапить свой входной тип на входной тип юзкейса. Часто конечно этого могут не делать, ибо они совпадают. Но в rest так не получится, т. к. часто передаются данные в params и query. А это всегда строки. И получается что нужен валидатор в контроллере - потом маппинг - потом уже валидатор на юзкейсе.
Да. Мы сделали систему кверей, где описаны правила валидации и потом в модельке подтягивываем нужную. Выходит норм, хоть и спорно
YZ
Спасибо, ознакомлюсь
DL
Грубо говоря да, необходимость в этом слое появилась чтоб использовать несколько сервисов и не дублировать эту логику в контролерах
А Вы в usecase модель прикидываете или dto?
YZ
А Вы в usecase модель прикидываете или dto?
Dto
DL
Есть от этого профит учитывая доп маппинг с dto в модель и обратно?