Промежуточное ПО ядра asp.net против фильтров

Question

Прочитав о промежуточном программном обеспечении ядра asp.net, я запутался, когда мне следует использовать фильтры и когда мне следует использовать промежуточное программное обеспечение, поскольку оно, кажется, достигает той же цели. Когда следует использовать связующее ПО вместо сборщиков?

Answer 1

На канале 9 есть видео об этом: ASP.NET Monsters # 91: Middleware vs. Filters. Подводя итог видео:

Начинается выполнение запроса, и у нас есть промежуточное программное обеспечение и другое промежуточное программное обеспечение, представляемое как "русские куклы внутри кукол", и в конечном итоге включается промежуточное программное обеспечение маршрутизации, а затем запрос переходит в магистраль MVC. Поэтому, если вам не требуется контекст MVC (скажем, вы беспокоитесь о потоке и выполнении, например, отвечаете на заголовки каким-то механизмом предварительной маршрутизации и т. Д.), Тогда используйте промежуточное ПО.
Но если вам нужен контекст MVC и вы хотите действовать против действий, используйте фильтры.

Answer 2

Промежуточное программное обеспечение работает на уровне ядра ASP.NET и может выполнять любые запросы, поступающие в приложение.

С другой стороны, фильтры MVC работают только для запросов, поступающих в MVC.

Так, например, если бы я хотел обеспечить выполнение всех запросов через HTTPS, мне пришлось бы использовать для этого промежуточное программное обеспечение. Если бы я сделал фильтр MVC, который сделал бы это, пользователи могли бы по-прежнему запрашивать, например, статические файлы по HTTP.

Но с другой стороны, то, что регистрирует длительности запросов в контроллерах MVC, может быть фильтром действий.

Answer 3

Выполнение middlewareпроисходит до того, как контекст MVC станет доступным в конвейере. То есть,middleware не имеет доступа к ActionExecutingContext или ActionExecutedContextв случае, например, ActionFilter. У вас есть доступ кHttpContext, что позволит вам выполнять действия как над запросом, так и над ответом. Поскольку привязка модели еще не произошла, использование промежуточного программного обеспечения не подходит для запуска функции проверки или изменения значений.Middleware также будет выполняться при каждом запросе независимо от того, какой контроллер или действие вызывается.

С другой стороны, filtersбудет работать только с указанными действиями и контроллерами, если вы не зарегистрируете фильтр глобально при запуске. Поскольку у вас есть полный доступ к контексту, вы также можете получить доступ к контроллеру и самому действию.

Источник и пример: dotnetcultist.com

Answer 4

Конвейер фильтров во многом похож на конвейер промежуточного программного обеспечения, но у них также есть некоторые отличия, которые следует учитывать при принятии решения о том, какой подход использовать.

В чем сходство:

• Входящие запросы проходят через компонент промежуточного программного обеспечения, а исходящие ответы на эти запросы снова проходят через то же промежуточное программное обеспечение при переходе к клиенту. Некоторые фильтры (ресурс, действие и результат) также являются двусторонними, другие (авторизация и исключение) запускаются только один раз для запроса, а фильтры страниц (для страниц Razor) запускаются три раза.
• ПО промежуточного слоя может сократить запрос, напрямую возвращая ответ, вместо того, чтобы выполнять весь конвейер ПО промежуточного слоя и не передавать запрос более поздним ПО промежуточного слоя. Фильтры также могут замыкать конвейер фильтрации, напрямую возвращая ответ.
• Промежуточное программное обеспечение используется для сквозных задач (например, для ведения журнала, профилирования производительности или обработки исключений). Фильтры также используются для решения сквозных задач.

В чем отличия:

• Промежуточное ПО может работать для всех запросов, а фильтры будут работать только для запросов, которые достигают и выполнить действие из контроллера API или страницы Razor.
• Фильтры имеют доступ к компонентам MVC (например: или же ). ПО промежуточного слоя работает на более низком уровне по сравнению с фильтрами и не зависит от MVC и Razor Pages, поэтому оно не может использовать ни один из этих связанных компонентов.
• Фильтры предназначены для применения к подмножеству запросов, а не ко всем из них. Например, мы можем применить фильтр к одному контроллеру или одной странице Razor. Напротив, промежуточное программное обеспечение не имеет такого дизайна.

Итак, при попытке выяснить, что следует использовать: фильтры или промежуточное программное обеспечение, ответ должен исходить из приведенного выше сравнения. В качестве TL;DR:

• промежуточное ПО — это более общая концепция, которая работает с абстракциями более низкого уровня, такими как , поэтому может применяться в более широкой области. Также мы должны осознавать тот факт, что функциональность, которую нам нужно реализовать, не имеет требований, специфичных для MVC.
• фильтры могут позволить нам использовать MVC-конструкции и могут использоваться для реализации пользовательского и специального поведения для некоторых действий MVC. Это не так универсально, как промежуточное ПО.

Answer 5

По моему опыту, ПО промежуточного слоя можно использовать для всего конвейера запросов, но фильтры используются только в ПО промежуточного слоя маршрутизации, где у нас есть конвейер MVC, поэтому ПО промежуточного слоя работает на уровне ядра ASP.NET, а фильтры выполняются только тогда, когда запросы поступают в конвейер MVC. .