Все запросы к IIS, обрабатываются с помощью Internet Server Application Programming интерфейса (ISAPI) расширениями. ASP.NET имеет свой собственный фильтр, чтобы заставить страницы обрабатываются правильно. По умолчанию, ASP.NET ISAPI фильтр (aspnet_isapi.dll) обрабатывает только ASPX, ASMX, и некоторые другие файловые форматы, используемые .NET и Visual Studio. Тем не менее, этот фильтр может быть зарегистрирован с другими расширениями, для того чтобы обрабатывать запросы на другие типы файлов.
Каждый запрос через HTTP проходит через модулеи, которые охватывают различные области применения (например, аутентификация и информация сессии). После прохождения каждого модуля, запросу присваивается единый HTTP обработчик, который определяет, каким образом система будет реагировать на запрос. По завершении обработки запроса, ответ проходит обратно через поток HTTP модулей и после чего передается пользователю.
HTTP modules
HTTP модули выполняются до и после обработки и обеспечивают метод для взаимодействия с запросом. Пользовательские модули должны быть унаследованы от System.Web.IHttpModule интерфейса. Модули, как правило, синхронизированы с событиями System.Web.IHttpModule класса (осуществляемого в рамках Global.asax.cs или. .vb. файла).
Модуль может перехватить следующие события:
- BeginRequest
- AuthenticateRequest
- AuthorizeRequest
- ResolveRequestCache
- AcquireRequestState
- PreRequestHandlerExecute
- PostRequestHandlerExecute
- ReleaseRequestState
- UpdateRequestCache
- EndRequest
- PreSendRequestHeaders (*)
- PreSendRequestContent (*)
- Error (*)
События, отмеченные звездочкой (*) могут произойти в любое время в течение запроса; все остальные перечислены в порядке их вызова.
HTTP Handlers
HTTP обработчики в целом отвечают за разработку бизнес-логики, привязанной к запросу. Пользовательские обработчики должны унаследовать System.Web.IHttpHandler интерфейс.
Кроме того, может быть создан фабричный класс обработчика который будет анализировать запрос, чтобы определить, какой HTTP обработчик является целесообразным.
Пользовательский фабричный класс обработчика должен унаследовать System.Web.IHttpHandlerFactory интерфейс.
Подробнее о Handlers …
Возможности использования модулей и обработчиков. При всех вариантах, имеющихся в ASP.NET, иногда бывает трудно определить, какое решение лучше соответствует вашим потребностям. Конечно, лучше сохранить код простым, но все равно надо учитывать эволюционные соображения и опыт, уровень нынешних и будущих членов команды которые работают над проектом
Оба, модули и обработчики добавляют дополнительный слой, что может быть сложно для начинающих и/или программистов, которые пользуются шаблонами программирования.
Во-первых, решите, что должен делать ваш модуль или обработчик. Некоторые функции, такие как аутентификация и инструментарий могут быть добавлены в рамках модулей.
Модули должны быть рассмотрены только тогда, когда есть необходимость в прохода и/или перехвата взаимодействия с запросом.
И наоборот, обработчики должны быть созданы, если есть необходимость в прямых функциональных действиз на один или более частей приложения.
Вероятно, наиболее частое, использование HTTP погрузчиков состоит в том, изменить запросы и установить их для различных компонентов в рамках вашего приложения без осуществления таких изменений в каждой странице.
Использовать или нет?
Большинство приложений, не требуют такого уровня обхода. Некоторые методы, такие как PageController схема, позволяют для общей функциональности нескольких страниц, включать логику в базовый класс System.Web.UI.Page объекта, и наследовать от него каждую веб-страницу. При просмотре PageController реализации, вы должны знать и понимать необходимость использования наследования. Хотя некоторые вещи можно сделать таким образом (то есть разрешение и приборов), это не всегда правильно. Вы должны полностью понять преимущества / недостатки использования обоих модулей и погрузчиков, прежде чем принимать решение о выборе одного или другого.
Заключение
HTTP модули и обработчики могут быть сложными. Потребуется времени для того чтобы полностью понять их плюсы и недостатки до реализации решения. Рекомендуется использовать опыт программных архитекторов в вашей организации или сообщества.
Метки:ASP.NET, C#, разработка
Похожие статьи
- 30 декабря 2008 -- Создаем ASHX хендлер в ASP.NET (1)
- 22 августа 2008 -- Собственная страница для обработки ошибок на ASP.NET (0)
- 15 октября 2008 -- Visual studio 2008 вылетает. (0)
- 27 августа 2008 -- Кеширование ASP.NET страниц браузером. (2)
- 15 сентября 2011 -- C#: Запуск Windows сервисов как консольных приложений (5)