Когда использовать HttpMessageHandler против ActionFilter?

Кажется, что эти два имеют аналогичную цель. Было бы здорово увидеть некоторые примеры, когда нужно использовать один за другим, за и против, а также указать, каковы основные отличия.

Ответ 1

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

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

Ответ 2

Большая разница между обработчиками и фильтрами действий - это этап, на котором они выполняются. Фильтры действий выполняются после того, как произошла диспетчеризация диспетчера и привязка модели, поэтому у вас есть возможность взаимодействовать с экземпляром контроллера, который обрабатывает запрос, а также имеет прямой доступ к типизированным объектам модели, которые передаются методу действия. Я использовал этот подход для выполнения расширенного ведения журнала значений запроса/ответа - потому что я мог получить доступ к контроллеру, я смог записать дополнительную информацию о том, как обрабатывался запрос.

Обработчики сообщений выполняются ранее в этом процессе и работают гораздо ближе к исходным значениям запроса/ответа, чем фильтры (контрастируют объекты HttpRequestMessage/HttpResponseMessage, используемые в обработчиках с гораздо более богатыми объектами HttpActionContext и HttpActionExecutedContext, доступными в фильтрах). Это делает их потенциально более эффективными для некоторых видов деятельности, например, если вы пытаетесь определить, нужно ли раньше разорвать запрос. Если вы знаете, что запрос должен быть отклонен, обработчик позволит вам сделать это до того, как инфраструктура WebApi перейдет к созданию экземпляра контроллера, выполнению привязки модели и т.д.

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