2012-06-20 4 views
39

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

+1

http://forums.asp.net/t/1804456.aspx – user960567

+3

Лучше может быть вопрос, когда использовать HttpMessageHandler против * global * ActionFilter. Это кажется немного более туманным. Фильтры –

ответ

53

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

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

enter image description here

+6

также могут применяться ко всем HTTP-запросам, если они добавлены в качестве глобальных фильтров. – frennky

+2

Где это? –

+2

http://blogs.msdn.com/b/kiranchalla/archive/2012/05/05/asp-net-mvc4-web-api-stack-diagram.aspx –

26

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

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

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

Смежные вопросы