Ознайомившись із основним проміжним програмним забезпеченням asp.net, мене бентежить, коли слід використовувати фільтри, а коли - проміжні, оскільки, здається, вони досягають тієї ж мети. Коли слід використовувати проміжні засоби замість штуцерів?
основне проміжне програмне забезпечення asp.net проти фільтрів
Відповіді:
Про це є відео на каналі 9: ASP.NET Monsters # 91: Middleware vs. Filters . Підсумовуючи відео:
Виконання запиту починається, і ми маємо проміжне програмне забезпечення та інше проміжне програмне забезпечення, подумайте про це, як про "російських ляльок всередині ляльок", і врешті-решт проміжне програмне забезпечення маршрутизації запускається, а потім запит надходить у пілот MVC.
Отже, якщо вам не потрібен контекст MVC (скажімо, вас турбує потік та виконання, наприклад відповідь на заголовки, якийсь механізм попередньої маршрутизації тощо), тоді використовуйте проміжні засоби .
Але якщо вам потрібен контекст MVC і ви хочете оперувати діями, використовуйте фільтри .
Отже, якщо у мене є логіка, я хочу запускати кожен запит (наприклад, ведення журналу), лише деякі з яких пов’язані з MVC, я б помістив це в проміжне програмне забезпечення, а потім нехай обробник фільтра виконує будь-яку конкретну логіку, яка може знадобитися для цього, тоді повернути до проміжного програмного забезпечення?
—
Terry H
Проміжне програмне забезпечення працює на рівні ASP.NET Core і може реагувати на кожен окремий запит, що надходить до програми.
З іншого боку, фільтри MVC працюють лише для запитів, які надходять до MVC.
Так, наприклад, якби я хотів домогтися того, що всі запити повинні виконуватися через HTTPS, мені довелося б використовувати проміжне програмне забезпечення для цього. Якби я зробив MVC-фільтр, який це робив, користувачі все одно могли б запитувати, наприклад, статичні файли через HTTP.
Але з іншого боку, те, що реєструє тривалість запитів у контролерах MVC, може бути абсолютно фільтром дій.
Виконання middlewareвідбувається до того, як контекст MVC стане доступним у конвеєрі. Тобто middlewareне має доступу до ActionExecutingContextабо, наприклад, ActionExecutedContextу випадку ActionFilter. До чого ви маєте доступ, це те HttpContext, що дозволить вам виконувати дії щодо запиту, а також відповіді. Оскільки прив'язка моделі ще не відбулася, використання проміжного програмного забезпечення не підходить для запуску функції перевірки або модифікації значень. Middlewareтакож буде виконуватися при кожному запиті, незалежно від того, який контролер або дія викликається.
З іншого боку, filtersпрацюватиме лише за певними діями та контролерами, якщо тільки ви не зареєструєте фільтр глобально під час запуску. Оскільки у вас є повний доступ до контексту, ви також можете отримати доступ до контролера та самої дії.
Джерело та приклад: dotnetcultist.com