Size: a a a

2021 July 10

СА

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

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

AS

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

AA

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

ИМ

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

AS

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

СА

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

ИМ

Илья Макеев... in ctodailychat
как вариант, но возможно не так удобно)
источник

AP

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

AP

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

A

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

AP

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

IV

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

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