Asp события приложения


Глобальные события приложения

Привет!
ASP NET MVC 5.

Если я в Global.asax добавляю метод protected void Application_EndRequest(object sender, EventArgs e) , то с каждым запросом он вызывается. Если же я в том же Global.asax в методе Application_Start напишу:

То в этом случае MyEndRequest не вызывается.

20.06.2020, 18:02

События запуска и останова приложения
Мне нужно для каждого пользователя запускать логгер, а когда пользователь отключается — записывать.

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

Глобальные события мыши и клавиатруы
Я знаю подобные темы уже были но я не смог разобраться ни в хуках ни в библиотеке. Мне нужно.

Глобальные события в Visual Basic 6
Подскажите, кто знает. Необходимо в программе, реализованной на VB 6 обработать событие (мыши.

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

IT-ЗАМЕТКИ

Инструменты пользователя

Инструменты сайта

Содержание

Типы файлов ASP.NET

Global.asax

Файл global.asax позволяет записывать обработчики событий, реагирующие на глобальные события. Пользователи не могут запрашивать файл global.asax напрямую.

В каждом файле global.asax определены методы для единственного класса — класса приложения. Класс приложения унаследован от HttpApplication, что позволяет работать в коде со всеми его общедоступными и защищенными членами.

В данном примере метод Application_OnEndRequest() выводит в нижней части страницы колонтитул с датой и временем ее создания.

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

События приложения

В файле global.asax могут обрабатываться события двух следующих типов:

Обязательные события разворачиваются в описанном ниже порядке:

Некоторые события срабатывают не при каждом запросе:

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

Демонстрация событий приложения

В следующем веб-приложении используется файл global.asax, который реагирует на событие HttpApplication.Error. Он перехватывает ошибку и отображает некоторую информацию в предопределенном формате:

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

web.config

Каждое веб-приложение наследует параметры настройки из файла machine.config и корневого файла web.config. Кроме того, параметры могут применяться к отдельным веб-приложениям. Например, в веб-приложении может быть предусмотрен специфический метод аутентификации, тип отладки, язык по умолчанию или специальные страницы сообщений об ошибках. Чтобы сделать это, понадобится добавить в корневой виртуальный каталог своего веб-приложения файл web.config. Для конфигурирования отдельных подкаталогов в веб-приложении в них следует поместить дополнительные файлы web.config.

Важно понимать, что файл web.config в веб-приложении не может переопределять все параметры в файле machine.config. Некоторые параметры в этом файле, такие как параметры модели процессов, не могут изменяться для каждого приложения отдельно. Другие параметры, наоборот, являются специфичными для приложений. Это значит, что их можно устанавливать в файле web.config, который находится в корневом виртуальном каталоге веб-сайта, но нельзя в файлах web.config, расположенных в подкаталогах.

Наследование конфигурации

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

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

Элемент является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе . Например, в следующем файле web.config элемент применяется для создания двух групп параметров настройки — для текущего каталога и для подкаталога Secure:

Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.

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

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

Некоторые базовые разделы конфигурации

Элемент Описание
authentication Этот элемент конфигурирует систему авторизации — другими словами, он определяет, как будут проверяться идентификационные данные клиента, когда он запрашивает страницу
authorization Этот элемент управляет тем, каким клиентам должен предоставляться доступ ресурсам, находящимся внутри веб-приложения или текущего каталога
compilation Этот элемент идентифицирует версию .NET, на которую ориентировано веб-приложение (посредством атрибута targetFramework) и указывает, должны ли генерироваться символы отладки в файлах .pdb (через атрибут debug), чтобы можно было отлаживать приложение с помощью инструмента, подобного Visual Studio.
customErrors Этот элемент позволяет указывать специфичные URL -адреса, которые должны использоваться для переадресации в случае возникновения определенных (или стандартных) ошибок. Например, он может использоваться для перенаправления пользователя с неприглядной страницы ошибки 404 (page not found — страница не найдена) на более дружественную по отношению к пользователю страницу. Хотя этот параметр работает с встроенным тестовым веб-сервером Visual Studio, в IIS 7.x он заменен разделом
membership Этот элемент позволяет конфигурировать систему членства ASP .NET, которая управляет информацией пользовательских учетных записей и предоставляет высокоуровневый API -интерфейс для решения связанных с безопасностью задач, таких как вход пользователя в систему и переустановка пароля
profile Этот элемент позволяет конфигурировать систему профилей ASP .NET, которая автоматически сохраняет и извлекает информацию по конкретному пользователю (обычно параметры профиля). Как правило, данные профилей сериализуются в базу данных
roleManager Этот элемент позволяет конфигурировать систему безопасности на основе ролей ASP .NET, которая предоставляет способ сохранения информации о ролях и высокоуровневый API -интерфейс для авторизации на основе ролей
sessionState тот элемент конфигурирует различные опции, касающиеся обслуживания состояния сеанса для приложения, такие как, должно ли оно вообще поддерживаться, и если да, то где (в SQL , отдельная служба Windows и т.д.)
trace Этот элемент конфигурирует трассировку, т.е. средство ASP .NET, которое позволяет отображать диагностическую информацию на странице (или собирать ее для отдельного просмотра)

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


Специальные параметры настройки в файле web.config добавляются в элемент . Все добавляемые специальные параметры записываются в виде простых строковых переменных.

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

После добавления такой информации .NET позволяет чрезвычайно легко извлекать ее в коде веб-страниц. Все, что понадобится — это просто использовать класс WebConfigurationSettings, который находится в пространстве имен System.Web.Configuration. Этот класс предоставляет статическое свойство AppSettings, в котором содержится динамически генерируемая коллекция всех доступных в текущем каталоге параметров приложения.

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

Построение приложений на основе веб-форм ASP.NET Web Forms

Модель событий

Обработка запроса и генерация страницы большой и сложный процесс, который происходит на стороне сервера. При обработке запроса в каждый момент времени сервер выполняет различные действия, которые в общем случае незаметны для пользователя приложения и разработчика. Зачастую для разработчика нет необходимости знать о процессах, которые происходят в рамках среды исполнения. Однако при реализации некоторых механизмов может потребоваться вмешаться в процесс обработки запроса. Например, это может быть необходимо, когда разрабатывается собственная система безопасности или реализуется сложный механизм кэширования страницы. В этом случае нужно каким-то образом вмешаться в процесс разработки и запустить собственный код. Для этих целей в ASP . NET существует модель событий, которая позволяет это сделать. В рамках этой модели существуют предопределенные события, которые запускаются каждый раз при обработке запроса от клиента в строго определенные моменты времени (например, в момент проверки корректности имени пользователя/пароля или в момент запроса данных из кэша).

Все события в модели событий ASP . NET можно разделить на два больших типа:

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

Рассмотрим механизм работы событий ASP.NET Web Forms, которые генерируются при каждом обращении к странице. Эти события можно разделить на группы, в зависимости от времени исполнения:

  • события, выполняющиеся в момент подготовки к обработке запроса;
  • события, выполняющиеся перед генерацией результата (кода HTML);
  • события, выполняющиеся после генерации результата.

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

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

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

В целом процесс генерации страницы можно представить следующим образом.

Давайте более подробно рассмотрим этапы обработки страницы:

Инициализация структуры страницы. На этом этапе ASP.NET создает страницу, генерируются все элементы управления, размещенные на странице. При обратном вызове (Postback) ASP.NET десериализует (преобразует в объектное представление) информацию из состояния вида ( Viewstate ) и применяет ее ко всем элементам страницы. На этом этапе запускается событие Page.Init . Однако это событие редко обрабатывают, поскольку объекты элементов управления еще не созданы и информация из Viewstate еще не загружена.
Инициализация кода пользователя. На этом этапе запускается событие Page.Load и запускается код самой страницы. Многие используют событие Page.Load для инициализации своих элементов управления. Важно, что Page.Load запускается всякий раз при загрузке страницы, даже при обратном вызове ( Postback ).
Проверка достоверности. На этом этапе у страницы вызывается метод Validate() , который перебирает все элементы управления валидатора и вызывает у него метод Validate() . На основе информации от валидаторов задается свойство страницы Page.IsValid .
Обработка пользовательских событий. На этом этапе элементы управления страницы созданы, а страница прошла проверку на достоверность. Теперь ASP.NET запустит все события элементов управления, происходившие с момента последней обратной отсылки ( Postback ), например, обработчики кнопок и других элементов управления.
Генерация страницы. На этом этапе ASP.NET запускает события генерации HTML-кода страницы. Генерация элементов управления происходит рекурсивно в рамках страницы.
Очистка. На данном этапе страница находится в конце своего жизненного цикла. В этот момент уже сгенерирован HTML код и повлиять на него уже невозможно. Однако объекты элементов управления до сих пор существуют. В этот момент начинается реальная очистка этих объектов и запускается событие Page.Unload .
Илон Маск рекомендует:  Что такое код connection_timeout

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

На каждое такое событие можно подписаться из своего кода и запускать в этот момент собственный код. Семантика каждого события заключается в следующем:

Application_BeginRequest срабатывает в начале каждого запроса, включая запросы на файлы, которые не являются Web-формами;
Application_AuthenticateRequest срабатывает до того, как будет выполнена аутентификация. Это стартовая точка для создания вашей собственной логики аутентификации;
Application_AuthorizeRequest срабатывает после того как пользователь пройдет процедуру аутентификации и ему нужно будет определить его права. Вы можете использовать данное событие для назначения специальных привилегий;
Application_ResolveRequestCache это событие обычно используется вместе с кэшированием выходных данных. В случае если есть кэшированные выходные данные для страницы, это – последний обработчик, который выполнится в модели событий;
Application_AcquireRequestState это событие вызывается перед тем, как для клиента будет получена информация, специфичная для сеанса и использована для заполнения коллекции Session ;
Application_PreRequestHandlerExecute это событие вызывается перед тем, как соответствующий HTTP обработчик выполнит запрос;
Application_PostRequestHandlerExecute это событие вызывается сразу после того, как будет обработан запрос;
Application_ReleaseRequestState это событие вызывается тогда, когда информация, специфичная для сеанса, сериализуется из коллекции Session , чтобы стать доступной для следующего запроса;
Application_UpdateRequestCache это событие вызывается перед добавлением информации в кэш выходных данных;
Application_EndRequest это событие вызывается в конце запроса перед тем, как объекты будут освобождены и восстановлены. Этот момент очень подходит для кода очистки.

Кроме этих событий, существует еще ряд глобальных событий, которые генерируются не при каждом обращении к странице, а при определенных условиях:

Application_Start вызывается тогда, когда впервые запускается приложение и создается домен приложения;
Session_Start вызывается каждый раз, когда начинается новый сеанс (инициируется сессия);
Application_Error вызывается всякий раз, когда в приложении возникает необработанное исключение (ошибка);
Session_End вызывается всякий раз при завершении сеанса (сессия удаляется из памяти);
Application_End вызывается сразу после завершения работы приложения. В этот момент можно выполнить критическую очистку памяти и освободить критические ресурсы;
Application_Disposed вызывается после завершения работы приложения, когда сборщик мусора .NET готов к восстановлению занимаемой приложением памяти. В этот момент уже поздно выполнять критическую очистку памяти, хотя вы можете последний раз узнать, были ли освобождены критические ресурсы.

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

Для того чтобы подписаться на любое из приведенных выше событий, можно воспользоваться двумя способами:

  • создать собственный HTTP-модуль, который будет встроен в среду исполнения HTTP;
  • использовать файл приложения global.asax.

Процесс создания собственного HTTP -модуля подробно рассмотрен далее, поэтому здесь мы не будем на нем останавливаться.

Для подписки на события из файла приложения global .asax, необходимо создать этот файл и определить в классе приложения методы, имена которых совпадают с именем события. Для того, чтобы создать файл приложения, необходимо выбрать пункт «Add new item» в контекстном меню веб-приложения.

После этого в появившемся окне необходимо выбрать соответствующий тип файла .

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

Для того, чтобы отследить обрабатываемые на странице события можно использовать встроенные в ASP . NET средства отладки, например, объект Debug . Для этого необходимо открыть разметку страницы и в директиве Page определить задать свойство Trace равное True .

После этого при обращении к странице будет отображаться отладочная информация . Среди прочей полезной информации будет содержаться информация о генерируемых событиях.

Для того чтобы отследить пользовательские события, давайте добавим на страницу поле ввода ( TextBox ) и кнопку ( Button ). После этого запустим проект, введем значение в поле ввода на странице и нажмем кнопку. При этом можно увидеть, что в процессе обработки появились новые события.

Таким образом, ASP . NET предоставляет полноценную инфраструктуру для отслеживания критических точек при обработке запроса. Все что необходимо сделать, чтобы вмешаться в обработку запроса – подписаться на событие и выполнить собственный код.


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

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

Существует ли в контексте ASP.NET MVC такое понятие как события?

Добрый день. Подскажите пожалуйста, есть ли в ASP.NET MVC возможность работать с событиями?
К примеру есть такой вот класс:

Возможно ли как то пробросить клиенту это событие? Или же в ASP.NET применяются другие возможности оповещения о которых я видимо еще не знаю.

  • Вопрос задан более года назад
  • 252 просмотра

Я не был в курсе существования этой библиотеки.
И, судя по описанию и комментарию ниже — она инкапсулирует WebSockets и несколько реализаций отправки сообщения с сервера на http.

Есть библиотека- хорошо. Но любая библиотека — слой абстракции над реальными способами решения проблемы.

1) Используйте Web API.
2) Используйте SignalR.

JS клиент SignalR будет эмулировать постоянный коннект с SignalR на сервере.
Вы получите то что хотите.

SignalR — это абстракция над несколькими способами реализации «реалтайма» между клиентом и сервером. Какой именно способо будет использоваться договорятся клиент и сервер самостоятельно или вы подкрутите нужные вам.

ASP.NET – обработка событий

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

События в ASP.NET вызываются на клиентском компьютере и обрабатываются на сервере. Например, пользователь нажимает кнопку, отображаемую в браузере. Событие Click происходит. Браузер обрабатывает это событие на стороне клиента, отправляя его на сервер.

На сервере есть подпрограмма, описывающая, что делать при возникновении события; это называется обработчиком событий. Поэтому, когда сообщение о событии передается на сервер, он проверяет, имеет ли событие Click связанный обработчик события. Если это так, обработчик события выполняется.

Аргументы событий

Обработчики событий ASP.NET обычно принимают два параметра и возвращают void. Первый параметр представляет объект, вызывающий событие, а второй параметр – аргумент события.

Общий синтаксис события:

События приложений и сессий

Наиболее важные события приложения:

Application_Start – возникает при запуске приложения / веб-сайта.

Application_End – возникает при остановке приложения / веб-сайта.

Application_Start – возникает при запуске приложения / веб-сайта.

Application_End – возникает при остановке приложения / веб-сайта.

Точно так же наиболее часто используемые события сеанса:

Session_Start – возникает, когда пользователь впервые запрашивает страницу из приложения.

Session_EndВозникает, когда сессия заканчивается.

Session_Start – возникает, когда пользователь впервые запрашивает страницу из приложения.

Session_EndВозникает, когда сессия заканчивается.

События страницы и управления

Общие страницы и управляющие события:

DataBinding – вызывается, когда элемент управления связывается с источником данных.

Уничтожено – поднимается, когда страница или элемент управления освобождаются.

Ошибка – это событие страницы, возникающее при возникновении необработанного исключения.

Init – вызывается при инициализации страницы или элемента управления.

Load – поднимается, когда страница или элемент управления загружены.

PreRender – вызывается, когда должна отображаться страница или элемент управления.


Выгрузить – поднимается, когда страница или элемент управления выгружаются из памяти.

DataBinding – вызывается, когда элемент управления связывается с источником данных.

Уничтожено – поднимается, когда страница или элемент управления освобождаются.

Ошибка – это событие страницы, возникающее при возникновении необработанного исключения.

Init – вызывается при инициализации страницы или элемента управления.

Load – поднимается, когда страница или элемент управления загружены.

PreRender – вызывается, когда должна отображаться страница или элемент управления.

Выгрузить – поднимается, когда страница или элемент управления выгружаются из памяти.

Обработка событий с использованием элементов управления

Все элементы управления ASP.NET реализованы в виде классов, и у них есть события, которые запускаются, когда пользователь выполняет над ними определенные действия. Например, когда пользователь нажимает кнопку, генерируется событие «Клик». Для обработки событий есть встроенные атрибуты и обработчики событий. Обработчик события закодирован, чтобы отвечать на событие и предпринимать соответствующие действия для него.

По умолчанию Visual Studio создает обработчик событий, добавляя предложение Handles в процедуру Sub. В этом разделе указывается элемент управления и событие, которое обрабатывает процедура.

Тег ASP для кнопки управления:

Обработчик события для события Click:

Событие также может быть закодировано без предложения Handles. Затем обработчик должен быть назван в соответствии с соответствующим атрибутом события элемента управления.

Тег ASP для кнопки управления:

Обработчик события для события Click:

Общие контрольные события:

Событие атрибут управления
Нажмите По щелчку Кнопка, кнопка изображения, кнопка ссылки, карта изображения
команда По команде Кнопка, кнопка изображения, кнопка ссылки
TextChanged OnTextChanged Текстовое окно
SelectedIndexChanged OnSelectedIndexChanged Выпадающий список, список, список переключателей, список флажков.
CheckedChanged OnCheckedChanged Флажок, переключатель

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

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

Например, события изменения или события выбора, такие как TextBox.TextChanged или CheckBox.CheckedChanged. События nonpostback могут быть отправлены обратно немедленно, если для их свойства AutoPostBack установлено значение true.

События по умолчанию

Событием по умолчанию для объекта Page является событие загрузки. Точно так же каждый элемент управления имеет событие по умолчанию. Например, событием по умолчанию для элемента управления кнопки является событие Click.

Обработчик событий по умолчанию можно создать в Visual Studio, просто дважды щелкнув элемент управления в режиме конструктора. В следующей таблице приведены некоторые события по умолчанию для общих элементов управления:

контроль Событие по умолчанию
AdRotator AdCreated
Маркированный список Нажмите
кнопка Нажмите
каландр SelectionChanged
CheckBox CheckedChanged
CheckBoxList SelectedIndexChanged
DataGrid SelectedIndexChanged
DataList SelectedIndexChanged
Выпадающий список SelectedIndexChanged
Гиперссылка Нажмите
ImageButton Нажмите
ImageMap Нажмите
LinkButton Нажмите
ListBox SelectedIndexChanged
Меню MenuItemClick
Переключатель CheckedChanged
RadioButtonList SelectedIndexChanged

пример

Этот пример включает в себя простую страницу с элементом управления надписью и кнопкой. Когда происходят события страницы, такие как Page_Load, Page_Init, Page_PreRender и т. Д., Он отправляет сообщение, которое отображается элементом управления меткой. Когда кнопка нажата, возникает событие Button_Click, которое также отправляет сообщение для отображения на ярлыке.

Создайте новый веб-сайт и перетащите элемент управления меткой и элемент управления на него из панели инструментов элемента управления. Используя окно свойств, установите идентификаторы элементов управления как .lblmessage. и .btnclick. соответственно. Установите свойство Text элемента управления Button как «Клик».

Файл разметки (.aspx):

Дважды щелкните в представлении конструктора, чтобы перейти к коду позади файла. Событие Page_Load создается автоматически без какого-либо кода. Запишите следующие понятные строки кода:

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

ASP.Net Web Forms приложения

Набор wcb-форм и других файлов создаст единое ASP.Nct Web Forms приложение, к которому пользователи отправляют запросы и получают HTML-ответы. Фактически, как показано на рис. 4.1, данное приложение состоит из среды выполнения, созданной специалистами компании Microsoft, и программного кода, созданного разработчиками для решения прикладной задачи. Разработчик должен уметь настраивать работу среды выполнения.

Контекст web-приложения

При обработке запросов к web-приложению среда выполнения создает его контекст – набор объектов, которые могут использоваться в web- приложении .для взаимодействия с ней. Описание основных классов, объекты которых составляют контекст web-приложения, приведено в табл. 4.5.

Классы контекста web-приложения

Класс

Описание

Объекты данного класса хранят состояние приложения и данные, доступные всем пользователям приложения

Объекты данного класса содержат всю информацию о текущем 1 ПТР-запросе и предоставляют методы работы с ней

Илон Маск рекомендует:  Как сделать надпись перевернутую на 90 градусов


Объекты данного класса содержат код формируемой I ITML-страницы ответа и предоставляют методы работы с ним

Объекты данного класса предоставляют вспомогательные методы для обработки запроса

Объекты данного класса содержат данные пользователя, доступные в текущем сеансе работы

Интерфейс к объекту, который содержит информацию о текущем пользователе (если она поддерживается)

Объекты данного класса содержат всю информацию о контексте выполнения запроса

Глобальные объекты данного класса позволяют выполнять временное хранение данных в кэше; среда выполнения сама определяет, когда эти данные могут быть удалены

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

Доступ к объектам контекста выполняется в основном с помощью свойств класса Page.

События web-приложення

При обработке запроса к web-приложению среда выполнения инициирует большой набор событий:

  • • события, связанные с wcb-приложением и сеансом работы пользователя;
  • • события, связанные с web-формой в целом (события класса Раде, жизненный цикл страницы);
  • • события, связанные с серверными ЭУ (события соответствующих им классов, жизненный цикл ЭУ).

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

События web-приложения также могут быть разделены на следующие два типа:

  • • события, возникающие в специальных случаях, как например, начало и окончание работы web-приложения (Application_Start и Application_End) и начало и окончание сеанса работы пользователя (Session_Start и Session_End);
  • • события, возникающие при обработке каждого НТТР-запроса (таких событий более 20), например BeginRequest, AuthenticateRequest, EndRequest и т. п.

Для создания обработчиков таких событий нужно в web- приложение добавить файл global.asex (команда Website=>AddNewltem) и включить в него методы – обработчики событий. Заготовки обработчиков событий для специальных случаев уже включены в файл global.asex, а обработчики событий для HTTP-запросов можно добавить. Связь события с обработчиком выполняется по имени метода обработчика. Методы-обработчики должны иметь специальные имена следующего вида: Application_OnXxxx(), где Хххх – название обрабатываемого события. Например, обработчик события окончания обработки НТТР-запроса EndRequest имеет следующий вид:

protected void Application_OnEndRequest() <

Response.Write(» Обработка НТТР-запроса закончилась в» +

При обработке запроса к web-форме среда выполнения также инициирует набор событий. Для обработки таких событий можно создать методы в программном коде web-формы (в файле aspx.cs).

Конфигурирование ASP.Net-приложения

Задание параметров работы среды выполнения и различных данных, требуемых для работы самого web-приложения, называется конфигурированием web-приложения. В ASP.Net конфигурирование выполняется с помощью набора XML-файлов конфигурации, которые наследуются друг от друга. Каждый XML-файл содержит набор установочных параметров работы web-приложения. Наследование файлов конфигурации означает, что дочерний файл конфигурации использует все установки, которые сделаны в родительском файле, но установки дочернего файла заменяют аналогичные установки, сделанные в родительском файле. Пример наследования файлов конфигурирования показан на рис. 4.7.

Рис. 4.7. Наследование файлов конфигурации

Конфигурирование начинается с файла machin.config, хранящегося в системном каталоге C:WindowsMicrosoft.NETFramework[Bepcna]Config, в котором задаются параметры запуска и функционирования среды выполнения. Следующим за machin.config является конфигурационный файл web.config (в том же самом системном каталоге), который содержит дополнительные установки, применяемые для всех ASP.Net- приложений web-сервера. Все web-приложения наследуют установки из этих двух файлов. Каждое приложение также имеет собственные файлы конфигурации web.config. Один файл должен быть включен в корневой виртуальный каталог web-приложения. Кроме этого, для задания специфических установок для подкаталогов (например, для задания прав доступа к содержащимся в них web-формам) в них также включаются свои файлы web.config, установки которых применимы только для данных подкаталогов.

Самый простой файл конфигурации имеет следующий вид:

«compilation debug-‘true» targetFramework=»4.0″/>

Элемент «system.web» содержит все специфические для ASP.Net- приложения установки. Они используются средой выполнения для задания особенностей работы данного web-приложения. Ниже показан

пример описания строки соединения с именем MyConString и параметра приложения с именем MyParam1::

Initial Catalog=aspnetdb; Integrated Security=True»

Элементы страниц ASP.NET

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

Блок называется блоком объявления кода. Тег

Серверные элементы управления.

Страницы ASP.NET могут содержать обычную HTML-разметку, которая будет отправлена клиенту без изменений. Кроме того они содержат т.н. серверные управляющие элементы – разметку, которая будет обработана перед отправкой, и, следовательно может быть подвергнута изменению. Эти элементы представляют собой либо обычные HTML-теги с атрибутом runat=»server» (HTML-элементы управления), либо специальные теги (Web-элементы управления), которые после обработки будут заменены на обычную HTML-разметку.

Серверные элементы управления дают пользователю возможность взаимодействовать со страницей, при этом их события могут обрабатываться на сервере.

В ходе обработки HTML-элементы управления заменяются на соответствующие HTML-теги. Разработчики декларируют, что эти элементы сохранены для преемственности с предыдущей технологией и рекомендуют вместо них употреблять Web-элементы управления.

При задании Web-элементов управления используется специальный синтаксис, который ASP.NET распознает при запуске страницы. Например, элементы , , . Каждому тегу элемента управления соответствует свой член класса страницы, что позволяет задавать их свойства программно в обработчиках событий.

Например, вместо того чтобы выводить текст через Response.Write Welcome «); %>, можно установить текст элемента управления, задав соответствующее свойство. Например, Label1.Text =»Welcome»; пользователь увидит одно и то же.

Серверные элементы управления могут создаваться и динамически в коде обработчиков событий.

Модель событий серверных элементов управления ASP.NET. ASP.NET позволяет программировать Web-страницы с использованием модели, основанной на событиях, аналогичной модели, применяемой в клиентских приложениях. При этом функционирование событий, вызываемых серверными элементами управления ASP.NET, отличается от функционирования событий в традиционных страницах HTML. Это различие, прежде всего, обусловлено отделением самого события от места его обработки. В клиентских приложениях события вызываются и обрабатываются на клиенте. Однако на страницах ASP.NET события, связанные с серверными элементами управления, вызываются на клиенте, а могут обрабатываются на сервере в рамках страницы ASP.NET.


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

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

Серверные элементы управления содержат ограниченный набор событий, которые обычно являются событиями нажатия. Некоторые серверные элементы управления поддерживают события изменений. Например, серверный элемент управления CheckBox создает событие CheckedChanged, если пользователь снимает или отмечает флажок. Некоторые серверные элементы управления поддерживают более абстрактные события. Например, серверный элемент управления Calendar создает событие SelectionChanged, более абстрактную версию события нажатия. События, которые происходят часто (и могут быть вызваны без уведомления об этом пользователя), например, событие onmouseover, для серверных элементов управления не поддерживаются. Для связывания события с обработчиком на сервере и клиенте у управляющих элементов предусмотрены разные атрибуты. У Web-элементов onclick – обработка на сервере, onclientclick — на клиенте, у HTML-элементов onclick – на клиенте, onserverclick – на сервере (поддерживается не для всех элементов).

Кроме того, есть отличия в отправке данных из формы на сервер для управляющих элементов HTML и Web. Обычно данные из формы в браузере отправляются при нажатии кнопки type=»submit», именно этот элемент создается при обработке Web-элемента управления
. Однако, для Web-элементов может быть задано свойство AutoPostBack=»true», что дает возможность инициации немедленной отправки данных при наступлении события, связанного с этим элементом.

Для элементов управления, объявленных на странице, событие можно привязать к методу, задав атрибут (свойство) в разметке элемента управления (например, OnClick=»Button1_Click»). При динамическом создании элементов управления (в коде) необходимо использовать явную привязку событий.

Для иллюстрации различий в использовании Web и HTML элементов управления рассмотрим следующий пример.

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

Сначала создадим страницу, используя серверные Web-элементы управления. Код страницы будет таким:

Элементы страниц ASP.NET

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

Блок называется блоком объявления кода. Тег

Серверные элементы управления.

Страницы ASP.NET могут содержать обычную HTML-разметку, которая будет отправлена клиенту без изменений. Кроме того они содержат т.н. серверные управляющие элементы – разметку, которая будет обработана перед отправкой, и, следовательно может быть подвергнута изменению. Эти элементы представляют собой либо обычные HTML-теги с атрибутом runat=»server» (HTML-элементы управления), либо специальные теги (Web-элементы управления), которые после обработки будут заменены на обычную HTML-разметку.

Серверные элементы управления дают пользователю возможность взаимодействовать со страницей, при этом их события могут обрабатываться на сервере.

В ходе обработки HTML-элементы управления заменяются на соответствующие HTML-теги. Разработчики декларируют, что эти элементы сохранены для преемственности с предыдущей технологией и рекомендуют вместо них употреблять Web-элементы управления.

При задании Web-элементов управления используется специальный синтаксис, который ASP.NET распознает при запуске страницы. Например, элементы , , . Каждому тегу элемента управления соответствует свой член класса страницы, что позволяет задавать их свойства программно в обработчиках событий.

Например, вместо того чтобы выводить текст через Response.Write Welcome «); %>, можно установить текст элемента управления, задав соответствующее свойство. Например, Label1.Text =»Welcome»; пользователь увидит одно и то же.

Серверные элементы управления могут создаваться и динамически в коде обработчиков событий.

Модель событий серверных элементов управления ASP.NET. ASP.NET позволяет программировать Web-страницы с использованием модели, основанной на событиях, аналогичной модели, применяемой в клиентских приложениях. При этом функционирование событий, вызываемых серверными элементами управления ASP.NET, отличается от функционирования событий в традиционных страницах HTML. Это различие, прежде всего, обусловлено отделением самого события от места его обработки. В клиентских приложениях события вызываются и обрабатываются на клиенте. Однако на страницах ASP.NET события, связанные с серверными элементами управления, вызываются на клиенте, а могут обрабатываются на сервере в рамках страницы ASP.NET.

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

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

Серверные элементы управления содержат ограниченный набор событий, которые обычно являются событиями нажатия. Некоторые серверные элементы управления поддерживают события изменений. Например, серверный элемент управления CheckBox создает событие CheckedChanged, если пользователь снимает или отмечает флажок. Некоторые серверные элементы управления поддерживают более абстрактные события. Например, серверный элемент управления Calendar создает событие SelectionChanged, более абстрактную версию события нажатия. События, которые происходят часто (и могут быть вызваны без уведомления об этом пользователя), например, событие onmouseover, для серверных элементов управления не поддерживаются. Для связывания события с обработчиком на сервере и клиенте у управляющих элементов предусмотрены разные атрибуты. У Web-элементов onclick – обработка на сервере, onclientclick — на клиенте, у HTML-элементов onclick – на клиенте, onserverclick – на сервере (поддерживается не для всех элементов).

Кроме того, есть отличия в отправке данных из формы на сервер для управляющих элементов HTML и Web. Обычно данные из формы в браузере отправляются при нажатии кнопки type=»submit», именно этот элемент создается при обработке Web-элемента управления
. Однако, для Web-элементов может быть задано свойство AutoPostBack=»true», что дает возможность инициации немедленной отправки данных при наступлении события, связанного с этим элементом.

Для элементов управления, объявленных на странице, событие можно привязать к методу, задав атрибут (свойство) в разметке элемента управления (например, OnClick=»Button1_Click»). При динамическом создании элементов управления (в коде) необходимо использовать явную привязку событий.

Для иллюстрации различий в использовании Web и HTML элементов управления рассмотрим следующий пример.

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

Сначала создадим страницу, используя серверные Web-элементы управления. Код страницы будет таким:

ASP.NET и разработка Web-приложений

Многие разработчики полагают, что технология ASP.NET является чем-то вроде продолжения ASP, т. е. что это, если так можно выразиться, перенесенная на платформу .NET версия ASP 3.0, несколько усовершенствованная и дополненная поддержкой новых языков. Подобное представление в корне неверно. ASP.NET является концептуально новой современной платформой, предназначенной для создания Web-приложений. Специалистами Microsoft в ASP.NET заложено все для того, чтобы сделать цикл разработки Web-приложения более быстрым, а поддержку — более простой.

Для начала мы обсудим новые возможности ASP.NET, и я подчеркну отличия от ASP, чтобы на конкретных примерах продемонстрировать новые принципы построения приложений для Internet, призванные максимально облегчить работу программистов.

Илон Маск рекомендует:  Директива RewriteLog файла .htaccess

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

Библиотеки. Теперь при написании приложений можно задействовать набор компонентов, поставляемых с .NET, а он достаточно велик. Использование библиотеки классов Common Language Runtime (CLR) уменьшает количество кода, ускоряет процесс разработки, установки и переноса приложения.

ADO.NET. В приложениях ASP.NET, как и в любом другом программном коде под .NET, можно использовать ADO.NET. Я упоминаю ADO.NET особо, чтобы подчеркнуть, насколько часто эта библиотека применяется при создании приложений на ASP.NET. Среди функций ADO.NET, используемых в ASP.NET, можно назвать, например, возможность сохранения набора данных в XML и загрузки его из XML, что упрощает разработку распределенных приложений на основе ASP.NET, а также полезно при передаче данных между Web-службами ASP.NET.

Поддержка средств разработки. Visual Studio.NET предоставляет возможность создания и редактирования приложений в режиме WYSWYG, включает в себя средства, упрощающие разработку и перенос приложений, а также отладку сценариев. Но, несомненно, никто не отнимает права написания кода в любимом редакторе, будь то CodeWright, EditPlus или NotePad.

Языковая независимость. ASP.NET работает в рамках Common Language Runtime, что позволяет писать код на любом языке, для которого существует компилятор, поддерживающий эту технологию. Сейчас имеется поддержка для JScript, VB, Perl и C#.

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

Обработка ошибок. В связи с новыми концепциями (в частности, с компиляцией программных текстов) в ASP.NET добавлены более широкие возможности обработки ошибок. На стадии разработки можно получить полную информацию об ошибке и листинг нужного куска кода. Для обработки ошибок, которые могут случиться во время выполнения приложения, можно использовать новую директиву ErrorPage.

Объектно-ориентированная разработка. Использование C# позволяет в полной мере задействовать концепции, методы и шаблоны объектно-ориентированной разработки.

Повторное применение. Помимо возможностей объектно-ориентированного программирования, ASP.NET представляет новые технологии, такие, как пользовательские элементы управления (user controls), новую концепцию установки (bin) и другие возможности.

Набор серверных компонентов ASP.NET. В комплект ASP.NET входят различные серверные компоненты: от самых простых (кнопка, список) до нестандартных и более функционально богатых (календарь).


Структура

Теперь немного поговорим о внутренней организации ASP.NET. Если продолжить сравнение с ASP, надо отметить, что в связи с описанными нововведениями внутренняя организация не могла остаться прежней. Если ASP представляла собой ISAPI DLL, с набором компонентов и несколькими системными файлами, то ASP.NET — часть глобальной платформы .NET. Создание этой платформы — важнейшее направление новой стратегии Microsoft; она соответствует всем современным стандартам разработки как для распределенных систем, так и для настольных приложений. На Рисунке 1 приведена схема, на которой показано взаимодействие различных частей .NET. Взаимодействие строится следующим образом: библиотека .NET Framework предоставляет интерфейс приложениям, а сама при этом взаимодействует непосредственно с операционной системой. Выше лежит интерфейс приложений ASP.NET, на котором, в свою очередь, базируются Web-формы (страницы ASP.NET) и Web-службы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки.

Рисунок 1. Схема работы .NET.

Intermediate Language — общий промежуточный язык, в который компилируется любой код под .NET, независимо от того, был ли он написан на C#, VB.NET или другом языке, — позволяет создавать системы на любом языке. И независимо от того, используется ли C#, VB.NET, JScript.NET или Perl.NET, на выходе получается готовый к выполнению код. На Рисунке 2 показана схема процесса компиляции и выполнения приложения ASP.NET. При запросе страницы проверяется, есть ли на диске ее скомпилированная версия и не обновлялась ли страница с момента компиляции. Если есть актуальная версия, она подгружается с диска и выполняется средой .NET. Результат выполнения страницы отсылается клиенту. Если же такая версия не была найдена, страница сначала компилируется. Для этого используются соответствующие компиляторы, которым на вход подается исходный код самой страницы, ее code-behind (т. е. непосредственно исполняемый код, стоящий за Web-формой, который написан отдельно — он может отсутствовать) и код элементов управления. Полученный в результате код сохраняется на диске. В некоторых случаях, а именно, когда в кэше имеется сохраненный результат обработки страницы, MSIL-код даже не приходится выполнять.

Рисунок 2. Схема работы ASP.NET.

На практике

Данный процесс кажется сложным, но разработчики всей этой сложности не замечают — процедура создания страниц ASP.NET достаточно проста. В подтверждение своих слов я хочу создать простейшую ASP.NET-форму. Для написания формы нужно сначала установить, собственно, ASP.NET. Установка начинается с получения комплекта .NET Framework SDK. Размер дистрибутива достигает 90 Мбайт, однако имеется возможность загрузки SDK в виде набора маленьких файлов. После загрузки требуется запустить файл setup.exe и следовать его инструкциям. ASP.NET распространяется как составная часть .NET SDK — сборника всех технологий, необходимых для создания, сборки и тестирования приложений, основанных на .NET Framework. Перед установкой ASP.NET следует инсталлировать Internet Explorer 6. NET SDK можно взять и с компакт-диска Windows Component Update из Visual Studio.NET. Если VS.NET на сервере установлен, то для того, чтобы запускать приложения ASP.NET, уже все есть.

Первую форму мы создадим с привлечением минимальных средств — нам падобится .NET Framework, Internet Information Services 5 и текстовый редактор. Создание формы начнем с написания приложения на Web-сервере. Создадим папку, в которой будет находиться приложение. Предположим, C:SampleApplication. Затем запустим Internet Services Manager. Создадим на сервере новый виртуальный каталог. Для этого нужно вызвать контекстное меню Web-сервера и выбрать пункт NewVirtual Director. На экране появится мастер Virtual Directory Creation Wizard. С его помощью нужно указать имя нового приложения, пусть это будет CustomApp. Далее следует указать каталог, в котором будут находиться файлы приложения. В нашем случае это C:SampleApplication. Следующий шаг — назначить права доступа к приложению (их можно оставить заданными по умолчанию). Далее в полученной папке создадим файл Default.aspx (см. Листинг 1).

Листинг 1. Default.aspx.

Опишу вкратце код этого листинга.

В первой строчке стоит директива @ Page, которая задает параметры страницы. Здесь, в частности, указано, что мы пишем на C#, что на странице у нас будет проводиться дополнительная программная обработка, определенная в файле Default.aspx.cs (мы его еще напишем), а наследоваться страница будет от класса Default (который будет описан в файле Default.aspx.cs).

Далее следует форма. Все серверные элементы управления должны быть включены в серверную форму (

ASP.Net Web Forms приложения

Набор wcb-форм и других файлов создаст единое ASP.Nct Web Forms приложение, к которому пользователи отправляют запросы и получают HTML-ответы. Фактически, как показано на рис. 4.1, данное приложение состоит из среды выполнения, созданной специалистами компании Microsoft, и программного кода, созданного разработчиками для решения прикладной задачи. Разработчик должен уметь настраивать работу среды выполнения.

Контекст web-приложения

При обработке запросов к web-приложению среда выполнения создает его контекст – набор объектов, которые могут использоваться в web- приложении .для взаимодействия с ней. Описание основных классов, объекты которых составляют контекст web-приложения, приведено в табл. 4.5.

Классы контекста web-приложения

Класс

Описание

Объекты данного класса хранят состояние приложения и данные, доступные всем пользователям приложения

Объекты данного класса содержат всю информацию о текущем 1 ПТР-запросе и предоставляют методы работы с ней

Объекты данного класса содержат код формируемой I ITML-страницы ответа и предоставляют методы работы с ним

Объекты данного класса предоставляют вспомогательные методы для обработки запроса

Объекты данного класса содержат данные пользователя, доступные в текущем сеансе работы

Интерфейс к объекту, который содержит информацию о текущем пользователе (если она поддерживается)

Объекты данного класса содержат всю информацию о контексте выполнения запроса

Глобальные объекты данного класса позволяют выполнять временное хранение данных в кэше; среда выполнения сама определяет, когда эти данные могут быть удалены

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

Доступ к объектам контекста выполняется в основном с помощью свойств класса Page.

События web-приложення

При обработке запроса к web-приложению среда выполнения инициирует большой набор событий:

  • • события, связанные с wcb-приложением и сеансом работы пользователя;
  • • события, связанные с web-формой в целом (события класса Раде, жизненный цикл страницы);
  • • события, связанные с серверными ЭУ (события соответствующих им классов, жизненный цикл ЭУ).

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

События web-приложения также могут быть разделены на следующие два типа:

  • • события, возникающие в специальных случаях, как например, начало и окончание работы web-приложения (Application_Start и Application_End) и начало и окончание сеанса работы пользователя (Session_Start и Session_End);
  • • события, возникающие при обработке каждого НТТР-запроса (таких событий более 20), например BeginRequest, AuthenticateRequest, EndRequest и т. п.

Для создания обработчиков таких событий нужно в web- приложение добавить файл global.asex (команда Website=>AddNewltem) и включить в него методы – обработчики событий. Заготовки обработчиков событий для специальных случаев уже включены в файл global.asex, а обработчики событий для HTTP-запросов можно добавить. Связь события с обработчиком выполняется по имени метода обработчика. Методы-обработчики должны иметь специальные имена следующего вида: Application_OnXxxx(), где Хххх – название обрабатываемого события. Например, обработчик события окончания обработки НТТР-запроса EndRequest имеет следующий вид:

protected void Application_OnEndRequest() <

Response.Write(» Обработка НТТР-запроса закончилась в» +

При обработке запроса к web-форме среда выполнения также инициирует набор событий. Для обработки таких событий можно создать методы в программном коде web-формы (в файле aspx.cs).

Конфигурирование ASP.Net-приложения

Задание параметров работы среды выполнения и различных данных, требуемых для работы самого web-приложения, называется конфигурированием web-приложения. В ASP.Net конфигурирование выполняется с помощью набора XML-файлов конфигурации, которые наследуются друг от друга. Каждый XML-файл содержит набор установочных параметров работы web-приложения. Наследование файлов конфигурации означает, что дочерний файл конфигурации использует все установки, которые сделаны в родительском файле, но установки дочернего файла заменяют аналогичные установки, сделанные в родительском файле. Пример наследования файлов конфигурирования показан на рис. 4.7.

Рис. 4.7. Наследование файлов конфигурации

Конфигурирование начинается с файла machin.config, хранящегося в системном каталоге C:WindowsMicrosoft.NETFramework[Bepcna]Config, в котором задаются параметры запуска и функционирования среды выполнения. Следующим за machin.config является конфигурационный файл web.config (в том же самом системном каталоге), который содержит дополнительные установки, применяемые для всех ASP.Net- приложений web-сервера. Все web-приложения наследуют установки из этих двух файлов. Каждое приложение также имеет собственные файлы конфигурации web.config. Один файл должен быть включен в корневой виртуальный каталог web-приложения. Кроме этого, для задания специфических установок для подкаталогов (например, для задания прав доступа к содержащимся в них web-формам) в них также включаются свои файлы web.config, установки которых применимы только для данных подкаталогов.

Самый простой файл конфигурации имеет следующий вид:

«compilation debug-‘true» targetFramework=»4.0″/>

Элемент «system.web» содержит все специфические для ASP.Net- приложения установки. Они используются средой выполнения для задания особенностей работы данного web-приложения. Ниже показан

пример описания строки соединения с именем MyConString и параметра приложения с именем MyParam1::

Initial Catalog=aspnetdb; Integrated Security=True»

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL