Сервис сейчас принимает на вход юзера. Можно переписать, чтобы принимал ID. В целом сервис должен устойчиво работать вне зависимости от того, существует переданный на вход юзер или только что был создан из воздуха.

Я скажу больше. Если мне в контроллер приехал ID буквенный или отрицательный - я могу ответить 400, что означает "никогда больше не приноси мне это говно". А если юзера с таким ID сейчас не нашлось - то это не значит, что он не найдётся при повторном запросе: он может быть сейчас деактивирован, а завтра восстановлен, или он меня забанил, а завтра разбанит. И надо говорить 404 или 403.

Кмк это как раз и есть правильное разделение. Валидация в контроллере это когда проверяют что формат ожидаемый, ну там емаил или guid. А существование юзера или возможность над ним сделать бизнес операцию - точно не контроллер, только сервис

да, отсуствие юзера тут скорее исключение чем ошибка формата запроса

звучит логично, по поводу тестов (иначе для чего еще работать с несуществующими пользователями?): я обычно подхожу со стороны базы - в транзакции создаю там сущности тем или иным образом и дергаю апи 🙂

Вообще замечаю что такие споры возникают чаще из-за расхождения терминологии, когда не вдаваясь в детали люди начинают называть все подряд валидацией или аутентификацией и потом спорить о принадлежности Х к слою вместо того чтобы остановиться и сказать например - а вы знаете, вот это действие это не валидация, это состояние домена, оно не должно находиться в этом слое вообще, к нему правила валидации не применимы и т.д.

А я делаю in-memory реализацию интерфейса репозитория - и подкладываю её под сервис. Есть опасность, что она разойдётся по функционалу с настоящей реализацией, немного страхуется юнит-тестами на сам интерфейс репозитория.

как вариант, но возможно не так удобно)

У меня это именно так и я свято верю что только так и правильно)

Ну не все, на самом деле таких методов которые только и дергают методы репозиториев не так много в реальной жизни, в большинстве случаем там еще и бизнеслогика всякая поверх, реальные исключения GetSomethingByID/GetSomethingByIDs

+, валидация бизнес-правил не место в контроллере. «а существует ли юзер», «а есть ли у него права», «а не задисейблен ли он» и тп.

Несколько недель назад мы обсуждали с моей подачи этот же вопрос, где каким валидация место, я помню что многие топили за контроллер, я остался при своём - контроллер сериализация/десериалищация + вызовы методов сервисов и все.

Странно что у сервиса UserService полно полезных методов. Условно там должен быть один метод Do и больше ничего. Исключение служебные методы для нужд DI (привет джава).

Если делать по фэншую, то перед контроллером нужно добавить middleware который подгрузит в контекст нужного пользователя.

хмм, тогда это middleware будет знать как провалидировать и разобрать запрос, достать из него пользователя, сходить за текущими пользовательскими привилегиями... И в один из рефакторингов такой слой просто переименуют в контроллер =)

Все почему-то думают, что речь про текущего залогиненного юзера, тогда как нет, ничего подобного. Залогиненный юзер конечно живёт в контексте и появляется там до того, как вызов доходит до контроллера.

+, ни разу не шляпа

в контроллере должна быть валидация пользовательсокго ввода

чтобы избежать слепой веры

я бы выдал уже тебе еще один ро на месте макса

Вот так работает иммунитет.

рад за тебя