необработанных исключений? И каждый метод действия контрролера должен всё-равно отслеживать все возможные исключения у себя, что бы вернуть пользователю корректное описание ошибки
Если контроллер отправляет данные в какой-нибудь сервис, то уже он должен обработать ошибку. Просто контроллер должен вернуть ошибку, а обрабатываться она должна в месте возникновения.
да, правильно понимаешь
если контроллер вызывает UserService, который вызывает UserRepository в методе которого происходит ошибка, контроллер же эту ошибку должен обработать, а не репозиторий
сервис должен обработать
и в каждом методе действия контроллера будет что-то типа try { .... return View(model); } catch { return new View("Error", "Описание ошибки"); }
UseExceptionHandler используется в случае совсем-совсем unexpected исключения, когда где-то в более глубоких слоях произошло неожиданное исключение как пример - ты внутри своего кода дёргаешь какое-то публичное API, и вдруг внезапно в один прекрасный день его разработчики изменяют контракт => твой код падает вот для примерно таких случаев и ставят заглушку UseExceptionHandler
я бы сделал это как-то так (код привожу примерный): Result<MyCoolModel> result = await _mediator.HandleAsync(request); if (result.Succeeded) { return View(result.Model); } else { ModelState.AddModelError(string.Empty, result.ErrorMessage); return View(); }
а зачем тут нужен медиатор? он только агрегирует все необходимые для обработки запроса сервисы? Зачем переносить логику обработки запроса в другое место?
медиатор на основе типа запроса выбирает соответствующий хэндлер, в который через Dependency Injection внедряются все сервисы, необходимые для обработки запроса плюсы: - код каждого отдельного хэндлера проще, чем код сервиса, где всё собрано в кучу - каждый хэндлер можно тестировать отдельно - у каждого хэндлера свои зависимости, в процессе обработки запроса инстанцируются только компоненты, необходимые для обработки конкретного запроса минусы: - кода становится больше, нужно уметь его логично организовать в понятную структуру
затем, что в идеале код экшена контроллера должен быть простым как валенок, в стиле "получил модельку из тела запроса, передал её дальше на обработку, сижу результат жду"
очень похоже на описание контррллера, asp core на основе запроса строит маршрут, выбирает соответствующий контроллер для обраьботки запроса, ищет метод и через DI внедряет необходимые сервисы для обработки запроса
и код контроллера неумолимо раздувается
А если просто: перекладывает все DI из одной большой кучи(контроллер) по маленьким (хэндлеры) К минусам ещё можно добавить затрудненную навигацию/отладку.
так если этот раздутый код просто переложить в мкдиатор, меньше же кода не станет
Молодец. Но читать и понимать становится легче
можно зато на каждый хэндлер тесты накидать, хоть модульные хоть интеграционные замокал сервисы, которые нужны хэндлеру, передал их в конструктор => профит
так не в медиатор жи
Обсуждают сегодня