Парни, что лучше всего передовать в аргумент метода. На первом

скрине метод MessageService, который обновляет текст у сообщения, в него я передаю айди создателя и контракт, который приходит в реквесте у контроллера. но что если передавать как аргумент тип Message, а проверку на принадлежность сообщения к какому либо ownerId вынести в контроллер, возможно тогда метод UpdateMessage будет более универсальным?

в контроллер можно вынести таким образом - сделать метод в сервисе ValidateOwnerMessage, который будет проверять принадлежит ли сообщение такому то айдишнику и будет возвращать сообщение => затем это сообщение прокидывать в аргумент метода UpdateMessage. Что думаете?

Если так сделать, то это позволит контроллеру не делать авторизацию вообще, просто "забыв" вызвать метод Validate. Можно было бы как раз наоборот сделать - внести сервис авторизации как зависимость в сервис обновления. Тогда ownerId вообще уйдет из api сервиса обновления.

я честно не особо понял, то что ты написал

21th
вот так бы это выглядело примерно с методом Valida...

Хороший способ. Единственное - имнование метода ValidateOwnerPostAsync немного сбивает с толку. И теперь Unauthorized не отличить от NotFound.

ну то есть думаешь, что лучше сделать как на скринах, в метод сервиса передавать тип Message, на скринах в данном случае Post

21th
вот так бы это выглядело примерно с методом Valida...

я бы прикрутил FluentValidation

ну проблема с тем что возвращать уже решена в новом проекте, я думаю там всегда 403

что он делает вкратце?

позволяет убрать валидацию моделей в отдельные классы-валидаторы и путем несложного кода интегрировать валидацию прямо в pipeline вызова. Тоесть ты пишешь public IActionResult MyAction([FromBody] MyModel m) { .... } и когда у тебя начинает выполняца action - ты можешь быть уверен что валидация прошла и модель валидна.

Нет, передавать тип Post не лучше, потому что для удаления передается много лишнего, и требуется чтение целого объекта из базы, и аллокация целого объекта в памяти.

21th
но ведь если расставить такие атрибуты и повесить ...

да но посомтри на скриншот -у тебя там значительно более пушистая валидация а не только Required

Смешивать валидацию и авторизацию не айс.

что значит пушистая валидация

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

Так если чтение можно сделать с условием, то и удаление можно сделать с условием. Или уперлись в ограничение EntityFramework?

Denisio 🇬🇪
я вот про это

про конвертацию в гуид - в новом проекте это вовсе убрано про валидацию - имеется в виду валидирование принадлежности поста к айди юзера

каким условием

В SQL есть только SELECT …. WHERE …, но и DELETE …. WHERE …. Раз вы делаете SELECT * from posts where MessageId = @messageId AND OwnerId = @ownerId То сможете сделать и DELETE from posts where MessageId = @messageId AND OwnerId = @ownerId

И к тому же, почему вас так волнует, что это делается в 2 запроса к базе? Сколько постов публикуются, и сколько удаляются?

не оптимизировано

Почему это нужно оптимизировать? Это создает существенную нагрузку?

Лол

не знаю, ну вот например одновремено удалят сообщение 10к людей, надо сделать 20к запросов, вместо 10к

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