Возможности расширения приложений ASP.NET

Модули HTTP

Модель разработки ASP.NET позволяет разработчику расширять структуру приложения за счет использования различных механизмов расширения. Одним из наиболее важных механизмов расширения являются HTTP-модули.

HTTP-модули – это объекты, которые загружаются в процессе работы приложения и позволяют запускать программный код на различных стадиях обработки запроса HTTP. При инициализации HTTP-модуля производится подписка на необходимые события модели событий ASP.NET, которые выполняются на соответствующих этапах жизненного цикла страницы. Если рассмотреть структуру среды выполнения с точки зрения загрузки программных компонентов расширения, то можно увидеть следующую картину.

В момент поступления запроса поочередно инициализируются все HTTP-модули, определенные в конфигурации приложения, в которых производится подписка на нужные события. После этого создается HTTP-обработчик (работа которого будет рассмотрена далее) и управление передается ему.

HTTP-модули могут использоваться как в приложениях ASP.NET Web Forms, так и в приложениях ASP.NET MVC Framework. Они встраиваются в цепочку обработки запроса веб-сервера Internet Information Services (IIS), в рамках которого работают все приложения ASP.NET.

Каждый HTTP-модуль является объектом .NET Framework, который реализует интерфейс IHttpModule. Этот интерфейс содержит два простых метода – Init и Dispose.

Метод Init запускается в момент инициализации HTTP-модуля. В рамках этого метода обычно происходит подписка на нужные события. Важно, что HTTP-модули загружаются один раз, при запуске веб-приложения. Все запросы к приложению обрабатывает один и тот же HTTP-модуль. Метод Init не будет вызван при обращении к странице, если запрос осуществляется к уже запущенному приложению.

Метод Dispose используется для освобождения ресурсов и вызывается в случае завершения всего приложения. Зачастую этот метод не содержит кода, и необходим только в том случае, когда необходимо явно освободить какие-либо ресурсы, которые были созданы модулем в момент инициализации.

Таким образом, жизненный цикл HTTP-модуля можно представить следующим образом.

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

Для того, чтобы определить логику HTTP-модуля, необходимо использовать события, которые доступны в рамках модели событий ASP.NET. Для того, чтобы подписаться на нужные события используется объект приложения HttpApplication, который передается в параметрах метода Init. Аналогично файлу приложения global.asax, в рамках HTTP-модуля можно подписаться на любые события цикла обработки запроса и приложения. Например, чтобы подписаться на событие BeginRequest можно использовать следующий код.

В данном случае мы создаем метод-обработчик события, и, используя объект приложения HttpApplication, подписываемся на событие. Аналогичным образом можно подписаться одновременно на несколько событий.

После создания HTTP-модуля необходимо уведомить среду исполнения о том, что необходимо использовать этот модуль при работе приложения. Для этого необходимо добавить информацию о HTTP-модуле в файл конфигурации приложения. Для этого используется конфигурационная секция "httpModules", которая расположена в секции "system.web". Для добавления нового модуля используется узел "add", который должен содержать атрибуты "name" и "type". Атрибут "name" содержит имя модуля, которое будет использоваться при мониторинге приложения. Атрибут "type" содержит полное имя класса модуля (включая пространства имен), а также имя сборки, если этот класс размещен во внешней сборке. Например, добавление модуля в приложение может выглядеть следующим образом.

После такого определения модуль будет загружен и проинициализирован при запуске приложения.

При исполнении приложения можно получить список всех используемых HTTP-модулей. Для этого можно использовать объект приложения HttpApplication, который содержит коллекцию Modules. Просмотреть информацию обо всех HTTP-модулях можно следующим образом.

HTTP-модули могут использоваться для реализации совершенно различных сценариев. Так, например, в существующей инфраструктуре ASP.NET содержится большой набор HTTP-модулей, которые реализуют различную логику. Среди таких HTTP-модулей присутствуют модули аутентификации (модуль безопасности), поддержки сессий, кэширования HTML-кода и др.

Удобство применения HTTP-модулей состоит в том, что однажды разработанный HTTP-модуль можно использовать во вновь создаваемом приложении. Для этого необходимо скопировать в проект сборку, содержащую модуль и разместить в конфигурационном файле информацию о HTTP-модуле. Кроме того, используя конфигурационный файл HTTP-модули можно очень удобно включать и отключать при отладке приложения. По этой причине HTTP-модули нашли широкое применение среди разработчиков приложений на базе ASP.NET.

Краткие итоги

HTTP-модули являются одним из наиболее важных механизмов расширения. HTTP-модули представляют собой классы, реализующие интерфейс IHttpModule. В рамках этого интерфейса доступно два метода – Init и Dispose. В методе Init производится подписка на события, содержащиеся в модели событий ASP.NET. Каждый HTTP-модуль загружается при запуске приложения и обрабатывает все запросы до тех пор, пока приложение не будет выгружено. Для подключения HTTP-модуля к существующей среде обработки запросов используется конфигурационный файл.

Обработчики HTTP

HTTP-обработчик – это конечная точка, которая обслуживает запрос к ресурсу. Фактически, HTTP-обработчик содержит код, который запускается для генерации результата для данного типа запросов. Например, ASP.NET Web Forms содержит собственный HTTP-обработчик, который содержит логику генерацию веб-форм. ASP.NET MVC Framework также содержит собственный обработчик, который передает дальнейшее управление внутренним механизмам ASP.NET MVC Framework (таблица маршрутов – контроллер – представление). С точки зрения среды обработки запросов HTTP-обработчик является конечной точкой.

Обычно разработчику веб-приложения не требуется разрабатывать собственные обработчики для страниц и ресурсов приложения – эти обработчики уже доступны в составе той платформы, которая используется на данный момент. Например, класс Page, который является базовым классом для веб-формы является реализацией HTTP-обработчика (реализует интерфейс IHttpHandler). Необходимость в разработке HTTP-обработчика может возникнуть тогда, когда необходимо передать клиенту какой-либо ресурс, который генерируется по собственному алгоритму. Например, можно создать собственный HTTP-обработчик, который передает клиенту изображение, сгенерированное в процессе обработки запроса или полученное из базы данных. В этом случае нет необходимости в использовании сложной цепочки обработки запроса веб-формы.

Как уже говорилось, HTTP-обработчик – это программный компонент, на который возложена ответственность за обслуживание запроса. Он представляет собой экземпляр класса, реализующего интерфейс IHttpHandler. Этот интерфейс содержит логическое свойство IsReusable и метод ProcessRequest.

Свойство IsReusable позволяет определить поведение обработчика при обращении к нему:

С точки зрения производительности приложения и эффективности используемых ресурсов наиболее предпочтительным является первый вариант, при котором один и тот же объект обрабатывает множество запросов. Второй вариант (создание нового объекта для каждого запроса) используется в случае, если объект обработчика хранит внутри себя некоторое состояние.

Метод ProcessRequest является входной точкой для обработки запроса. В нем содержится логика по генерации ответа клиенту. Как видно, этот метод в качестве параметра принимает объект HttpContext. Используя этот объект, можно получить доступ к остальным необходимым для обработки запроса объектам – Request, Response и др. Объект Response позволяет передавать данные клиенту. Для этого можно использовать методы Write, WriteFile и др. Например, для передачи строки пользователю можно использовать следующий код.

Аналогичным образом можно передавать клиенту более сложное содержимое, например, разметку HTML или бинарные данные (изображения, документы и т.д.).

Для реализации собственного HTTP-обработчика можно воспользоваться двумя способами – создать пустой класс и реализовать в нем интерфейс IHttpHandler или воспользоваться встроенным шаблоном в Visual Studio. В последнем случае Visual Studio создает для обработчика также файл с расширением ".ashx". Наличие такого файла позволяет обращаться к нему прямо из браузера. Например, к обработчику с именем MyHandler можно обратиться по адресу "http://…/MyHandler.ashx". Для добавления обработчика в проект подобным образом нужно воспользоваться пунктом меню "Add new item" в Visual Studio и выбрать тип файла "Generic Handler".

При создании HTTP-обработчика этим способом аналогично создается класс, реализующий интерфейс IHttpHandler.

В случае, если HTTP-обработчик создается как обычный класс, не имеющий ассоциированного с ним файла ".ashx", для его использования необходимо задать описание этого обработчика в конфигурационном файле. Для этого используется конфигурационная секция "httpHandlers", которая размещается в секции "system.web". Для добавления нового определения HTTP-обработчика используется узел "add", который содержит следующие атрибуты:

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

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

Если HTTP-обработчик выполняет какую-то длительную вычислительную операцию, то есть смысл реализовать асинхронный HTTP-обработчик. Идея асинхронных обработчиков состоит в том, то для выполнения длительной операции используется новый поток, а основном поток возвращается в пул потоков веб-серверов. После завершения выполнения длительной операции из пула потоков заново изымается основной поток, в рамках которого производится передача обработанной информации клиенту. Для реализации асинхронного обработчика, необходимо создать класс, реализующий интерфейс IHttpAsyncHandler, который содержит два дополнительных метода – BeginProcessRequest и EndProcessRequest. Метод ProcessRequest не используется. Метод BeginProcessRequest запускается для создания нового потока и инициации длительной операции, а второй выполняется после окончания длительной операции и возврата в основной поток. Такой подход позволяет экономить количество потоков в пуле потоков для выполнения длительных операций.

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

Расширения в рамках приложений ASP.NET MVC Framework

Платформа ASP.NET MVC Framework имеет ряд собственных механизмов, упрощающих расширение функциональности приложения. Расширение возможностей приложения ASP.NET MVC Framework обычно осуществляется за счет наличия в структуре ASP.NET MVC Framework объектов ActionResult и ActionFilter.

Как известно из принципа работы приложения на базе ASP.NET MVC Framework, процесс обработки запроса представляется следующей последовательностью:

В момент, когда контроллер выбирает представление, он создает объект, унаследованный от класса ActionResult. Этот класс является базовым классом для любых представлений ASP.NET MVC Framework. Фактически, каждое представление является объектом .NET Framework, унаследованным от ActionResult. Так, например, для генерации представления на основе предопределенных шаблонов ASPX используется стандартный объект ViewResult, являющийся наследником объекта ActionResult.

Такой подход позволяет очень гибко подойти к формированию представлений. Например, если в какой-то ситуации требуется сформировать представление, отличное от стандартного, можно создать собственный объект, унаследованный от ActionResult и определить в нем логику генерации представления.

Хорошим примером расширения стандартных возможностей ASP.NET MVC Framework на основе переопределения представления является создание объекта, который генерирует RSS-ленту для приложения. В этом случае необходимо создать собственный объект и унаследовать его от ActionResult. При этом следует переопределить единственный метод базового класса ActionResult – ExecuteResult. Этот метод должен содержать все логику по формированию представления. Метод ExecuteResult принимает единственный параметр типа ControllerContext. В нем содержаться все данные, которые нужны для обработки запроса. К таким данным относится информация о контроллере, инициировавшем генерацию представления, данных о маршрутизации, а также все стандартные объекты ASP.NET, такие как Request, Response и т.д. Для передачи сгенерированного представления клиенту используется объект Response и его метод Write. Так, например, объект по генерации RSS-представления данных может иметь следующую реализацию.

В этом примере объект определенный нами RssView имеет конструктор, в котором принимает исходные данные. После этого в методе ExecuteResult происходит формирование XML-представления в соответствии со спецификацией RSS и передача результата клиенту.

После подобного определения объекта, отвечающего за формирование представление его необходимо использовать в рамках метода контроллера. Для этого необходимо вернуть объект определенного ранее класса RssView в качестве результата.

Это все, что необходимо сделать для определения собственного механизма по формированию представления. Аналогичным образом можно определить и другие объекты по формированию представления и использовать их по своему усмотрению. Как видно, для внедрения в инфраструктуру формирования представлений ASP.NET MVC Framework не требуется глубоко исследовать реализацию ASP.NET MVC Framework.

Другим важным механизмом расширения функциональности приложений ASP.NET MVC Framework являются фильтры действий контроллера – ActionFilter. С точки зрения конструкции языка C#, фильтры являются атрибутами, которыми помечаются действия контроллера. При этом существует возможность перехватить обработку действия контроллера и внедрить туда свою логику.

ASP.NET MVC Framework в своем составе уже имеет ряд важных фильтров, которые позволяют упростить разработку. К таким фильтрам относится, например, фильтр AcceptVers, который позволяет ограничить доступ к действию контроллера для определенных HTTP-методов. Например, в следующем примере обратиться к действию контроллера можно только используя HTTP-метод GET. Запросы, использующие другие HTTP-методы (POST, PUT, HEAD и т.д.) будут игнорироваться.

Другим примером готовых фильтров является элемент Authorize. Этот фильтр позволяет обращаться к действию контроллера только авторизированным пользователям, указавшим свое имя пользователя и пароль. В противном случае доступ к данном действию будет запрещен.

Более того, фильтр Authorize позволяет явно указать имена пользователей или набор групп пользователей, которым разрешен доступ к этому действию контроллера.

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

Каким образом реализуется функциональность фильтров? Для создания фильтра следует создать собственный класс, который является наследником базового класса ActionFilterAttribute. После этого можно переопределить два главных метода базового класса – OnActionExecuting и OnActionExecuted.

Два этих метода позволяют перехватить действия непосредственно перед и после выполнения действия. Таким образом, в этот момент времени можно определить собственную логику, например, в соответствии с какими-либо условиями ограничить доступ к действию контроллера или переопределить имя текущего представления. Как видно, каждый метод в качестве параметра принимает объект типа ActionFilterExecuting или ActionFilterExecuted соответственно. Эти методы содержат все необходимые данные для обработки текущего запроса.

Таким образом, ASP.NET MVC Framework содержит два важных и мощных инструмента для гибкого расширения функциональности веб-приложений.

Краткие итоги

Инфраструктура ASP.NET MVC Framework содержит дополнительные механизмы для расширения функциональности веб-приложения. К таким механизмам относятся возможность переопределения логики формирования представления на основе объекта ActionResult и фильтры ActionFilter. Создав собственную логику формирования представления на основе ActionResult можно удобно использовать ее при выполнении действия контроллера. Фильтры ASP.NET MVC Framework позволяют определить дополнительные правила при выполнении действия контроллера путем перехвата момента перед и после выполнения действия контроллера.

Контрольные вопросы