Следует ли при работе с фильтрами всегда устанавливать в качестве результата контекста объект ContentResult, если у вас есть что-то, что нужно вернуть?

Question

ContentResult позволяет вам указать как код состояния, который вы должны sh возвращать, так и содержимое вашего ответа и его кодировку.

Есть ли причина для возврата таких объектов, как OkObjectResult, BadRequestObjectResult et c по сравнению с простым возвратом ContentResult, при условии, что у вас действительно есть контент, который вы должны sh вернуть (т.е. ответ имеет тело, а не результат NoContentResult).

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

Спасибо.

Answer 1

• Если вы разработали WebApi и везде использовали ContentResult для каждого типа ответа, в какой-то момент вы бы столкнулись с разными разработчиками, сериализовавшими свои объекты в JSON в разных форматах. Смысл; стандартизация ..
• Эти дополнительные методы также предотвращают клонирование кода. Представьте, что вы возвращаете HTTP 500 с содержимым JSON с кодом и сообщением, чтобы сообщить клиенту об ошибке сервера и отобразить его. Что снова является лучшей практикой для дизайна WebApi. И вы использовали это 1000 раз в своем полном проекте. Тогда это означает, что вы вызываете свой метод сериализации Json 1000 раз, в то время как вы можете просто не использовать его вообще и оставить все это фреймворку. Когда придет время, и вы решите переключиться на новую, более оптимизированную библиотеку для JSON сериализации, вы в конечном итоге измените код на 1000 разных строк.
• Ваш код будет намного легче тестировать с этим дополнительным результатом типы. Вы можете написать правила модульного теста, чтобы сообщить тесту, что метод должен возвращать объект OkResult. Или можно написать правила для возвращаемых типов. При постоянном использовании ContentReult вам придется жестко закодировать свои методы тестирования и переключаться между значениями кода состояния HTTP, чтобы решить, что делать. Это означает, что больше операторов IF, больше строк означает большую сложность.

Таким образом, эти типы предназначены для разработчиков, которым они нужны, а не для разработчиков, которым они не нужны. Итак, если вам удобно использовать только ContentResult и у вас нет этих проблем, тогда все в порядке.

Answer 2

Если ваш контент является строкой, нет веских причин использовать конкретный результат c объекта - фактически это добавит накладные расходы, которые могут снизить производительность. ObjectResult полезен для кодирования объектов в запрошенный формат и, таким образом, выполняет дополнительные операции, чтобы проверить, как сериализовать данный объект.

Вы можете легко увидеть, что требуются дополнительные шаги, когда вы посмотрите на реализацию на Github:

ContentResult - это просто простой объект, наследующий непосредственно от ActionResult с некоторыми типизированными свойствами.

OkObjectResult - тонкий слой вокруг ObjectResult который просто устанавливает код состояния в своем конструкторе.

ObjectResult имеет сложные типы, такие как набор средств форматирования вывода, которые создают накладные расходы, поскольку их необходимо инициализировать.

Позже в конвейере ContentResult будет обрабатываться ContentResultExecutor, а ObjectResult будет обрабатываться ObjectResultExecutor.

ContentResultExecutor довольно прост, он в основном просто пишет закодированный результат в поток ответа.

ObjectResultExecutor не так просто, это на формирует такие операции, как проверка запрошенного типа вывода, определение типа данного объекта и сериализация объекта перед записью его в поток вывода.

Короче говоря: если вам просто нужно вернуть строку, используйте ContentResult. Если вам нужно вернуть сложный объект и вы хотите воспользоваться такими функциями, как автоматическое получение правильного формата вывода и оптимизированные для производительности процедуры сериализации, используйте какой-то тип ObjectResult.