A
легче будет развивать
Size: a a a
2021 July 10
A
тестировать
СА
Или в терминах гексагональной архитектуры, и контроллер, и репозиторий - это инфраструктурные адаптеры, но первый - транспортный (потому что веб), а второй - к БД.
A
ну в pure MVC 2010 годов никакого инфраструктурного слоя не было, был DAO, потом стали использовать Repository, но слой называли DAO, а не инфраструктурный.
почитаю, спасибо. ушел
почитаю, спасибо. ушел
ИМ
В контроллере сервис, в сервисе репозиторий, полностью корректно. У нас в вебе пользователя берут из кук, поэтому всегда можно придумать сервис, который без передачи параметра будет возвращать текущего пользователя, если он залогинен.
ИМ
а вот это такое: внешнему коду нужно знать устройство класса внутри зависимости
ИМ
контроллер это просто вызывалка нескольких методов сервиса, возможно еще обработка ошибок и логгирование где-то здесь же.
ИМ
при таком подходе можно переиспользовать сервис в какой-нибудь другой вызывалке без потерь
СА
Я не про аутентикацию, а если мне например надо контент другого пользователя получить
ИМ
getContent(userId, filterA, filterB)
СА
Вообще кажется, что я наткнулся на красивое решение: в контроллере оперировать только UserID, а все проблемы с тем, существует ли он - отдать сервису.
ИМ
ну да
ИМ
и пусть он исключения тровит
ИМ
а контроллер их логгирует
AA
Щас тебя затравят за валидацию не в контроллере
СА
Начинается все с GET /content/?byUserId=X Там же где-то куки или токен, но из них другой юзер порождается.
ИМ
а почему она должна быть в контроллере?
СА
Я могу валидировать сам ID. Что он числовой и больше нуля. Проверка, что такой юзер вообще существует - это, строго говоря, уже не валидация.
ИМ
в других местах при вызве метода сервиса не нужно валидировать данные?
ИМ
ну воооообще))) если есть фреймворк и в нем есть что-то такое https://symfony.com/doc/current/validation/custom_constraint.html то вполне можно сделать валидатор юзерайди, который сразу все сделает)))
