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

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

Это классы, в которых содержатся стандартные HTML-элементы. За исключением атрибута runat="server" объявление серверных элементов управления HTML ничем не отличается от объявления других элементов управления. Двумя наиболее яркими представителями серверных элементов управления являются HtmlAnchor и HtmlSelect

Веб-элементы управления

Эти классы дублируют функции базовых HTML-элементов, но обладают более согласованным и значащим набором свойств и методов, которые упрощают их объявление и доступ к ним. В качестве примеров можно назвать элементы управления HyperLink, ListBox и Button. Более того, несколько других типов элементов управления ASP. часто считаются особыми типами веб-элементов управления. В Visual Studio вы найдете базовые элементы управления на вкладке Standard в окне Многофункциональные элементы управления

Эти усовершенствованные элементы управления могут генерировать большой объем HTML-разметки и даже клиентский JavaScript-код для создания интерфейса. В качестве примеров можно назвать элементы управления Calendar, AdRotator и TreeView. В Visual Studio многие многофункциональные элементы управления доступны на вкладке Standard в окне Toolbox.

Элементы управления проверкой достоверности

Этот набор элементов управления позволяет быстро проверять достоверность связанного элемента управления ввода на предмет соблюдения нескольких стандартных или пользовательских правил.

Элементы управления данными

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

Элементы управления навигацией

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

Элементы управления входом в систему

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

Элементы управления Web Parts

Этот набор элементов управления поддерживает Web Parts — модель ASP NET для построения компонентных, легко конфигурируемых веб-порталов.

Элементы управления ASP.NET AJAX

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

Элементы управления ASP.NET Dynamic Data

Эти элементы управления поддерживают компонент ASP.NET Dynamic Data, который позволяет создавать управляемые данными веб-сайты за счет построения гибких шаблонов, а не написания утомительного кода.

Иерархия серверных элементов управления

Все серверные элементы управления унаследованы от базового класса Control из пространства имен System.Web.UI. Это верно при использовании серверных элементов управления HTML, применении веб-элементов управления или создании собственных специальных элементов управления. Это также относится к классу Page, от которого происходят все формы.

 

Приложения ASP.NET.

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

Домен приложения — это устанавливаемая средой CLR граница, которая гарантирует, что одно приложение не сможет влиять на другое приложение (или видеть хранящиеся в его памяти данные). Следующие характеристики являются прямым следствием модели домена приложения:

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

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

С помощью кода в файле global.asрx, расположенном в виртуальном каталоге приложения, можно присоединять обработчики событий, которые будут реагировать на эти глобальные события приложений.

Другими словами, виртуальный каталог является базовой групповой структурой, определяющей границы приложения ASP.NET. Допустимое приложение ASP.NET вполне может содержать единственную веб-форму (файл.aspx).

Для создания доменов приложений ASP.NET использует технологию отложенной, или "ленивой" инициализации. Это означает, что домен для веб-приложения создается при первом получении запроса на страницу в этом приложении.

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

Обновление приложений

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

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

 

 

Архитектура ADO.NET.

Платформа.NET Framework включает собственную технологию доступа к данным — ADO.NET. Эта технология состоит из управляемых классов, позволяющих приложениям.NET подключаться к источникам данных (обычно реляционным базам данных), выполнять команды и управлять автономными данными. Маленькое чудо ADO.NET заключается в том, что эта технология позволяет писать более-менее одинаковый код для доступа к данным — как в веб-приложениях, так и в клиент-серверных настольных приложениях, и даже в однопользовательских приложениях, подключаемых к локальной базе данных.

 

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

 

Поставщики данных в ADO.NET

Поставщик данных (dataprovider) — это набор классов ADO.NET, которые позволяют получать доступ к определенной базе данных, выполнять команды SQL и извлекать данные. По сути, поставщик данных — это мост между вашим приложением и источником данных.

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

Тип объекта	Базовый класс	Соответствующие интерфейсы	Назначение
Connection	Db	IDb	Позволяет подключаться к хранилищу данных и отключаться от него. Кроме того, объекты подключения обеспечивают доступ к соответствующим объектам транзакций
Command	Db	IDb	Представляет SQL-запрос или хранимую процедуру. Кроме того, объекты команд предоставляют доступ к объекту чтения данных конкретного поставщика данных
DataReader	Db	IDb	Предоставляет доступ к данным только для чтения в прямом направлении с помощью курсора на стороне сервера
DataAdapter	Db	IDb	Пересылает наборы данных из хранилища данных к вызывающему процессу и обратно. Адаптеры данных содержат подключение и набор из четырех внутренних объектов команд для выборки, вставки, изменения и удаления информации в хранилище данных
Parameter	Db	IDb	Представляет именованный параметр в параметризованном запросе
Transaction	Db	IDb	Инкапсулирует транзакцию в базе данных

Конкретные имена этих основных классов различаются у различных поставщиков (например, SqlConnection, OracleConnection, OdbcConnection и MySqlConnection), но все эти объекты порождены от одного и того же базового класса (в случае объектов подключения это DbConnection), который реализует идентичные интерфейсы (вроде IDbConnection). Поэтому если вы научитесь работать с одним поставщиком данных, то легко справитесь и с остальными.

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

 

В рамках.NET Framework поставляется небольшой набор из четырех поставщиков:

SQL Server- Предоставляет оптимизированный доступ к базам данных SQL Server (версии 7.0 и выше).

OLE DB- Предоставляет доступ к любому источнику данных, который имеет драйвер OLE DB. Это включает базы данных SQL Server версий, предшествующих 7.0.

Oracle- Предоставляет оптимизированный доступ к базам данных Oracle (версии 8i и выше).

ODBC- Предоставляет доступ к любому источнику данных, имеющему драйвер ODBC.

 

 

Cтандартизация в Адо.нет

Но даже несмотря на то, что разные поставщики данных.NET используют различные классы, все они некоторым образом стандартизированы. Точнее говоря, каждый поставщик основан на одном и том же наборе интерфейсов и базовых классов. Так, например, объект Connection реализует интерфейс IDbConnection, который определяет такие ключевые методы, как Open() и Close(). Подобная стандартизация гарантирует, что каждый класс Connection будет работать одинаковым образом и предоставит один и тот же набор ключевых свойств и методов.

"За кулисами" различные поставщики используют совершенно разные низкоуровневые вызовы и API-интерфейсы. Например, поставщик данных SQL Server применяет патентованный протокол TDS (TabularDataStream — поток табличных данных) для взаимодействия с сервером. Преимущества этой модели не сразу очевидны, но весьма существенны:

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

• Поскольку каждый поставщик реализован отдельно, он может использовать соответствующую оптимизацию. Кроме того, специализированные поставщики могут добавлять нестандартные средства, которых не имеют другие поставщики (например, возможность SQL Sever выполнять XML-запросы).

ADO.NET также имеет другой уровень стандартизации — DataSet. Класс DataSet — это контейнер данных общего назначения, которые извлекаются из одной или более таблиц источника данных. DataSet полностью обобщен; другими словами, специализированные поставщики не определяют собственных специализированных версий класса DataSet.

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

 

23. Транзакция — это набор операций, который должен либо выполниться успешно, либо не выполниться, причем как единое целое. Целью транзакции является гарантия того, что данные всегда находятся в корректном, согласованном состоянии.

Например, рассмотрим транзакцию, которая передает $1000 со счета A на счет B. Ясно, что здесь присутствует две операции:

• снять $1000 со счета А;

• добавить $1000 на счет B.

Предположим, что приложение успешно выполнило шаг 1, но из-за какой-то ошибки шаг 2 завершился сбоем. Это ведет к несогласованию данных, поскольку общая сумма денег в системе теперь не точна. Пропало $1000.

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

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

Атомарность (Atomic)

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

Устойчивость (Durable)

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

 

Применяйте SSL

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

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

Если вы пренебрегаете хотя бы одним из приведенных правил, то все прочие средства защиты становятся в большей или меньшей мере бесполезными.

 

Профили

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

В ASP.NET 1.x единственная практическая возможность сохранять специфичную для пользователя информацию состояла в создании собственных компонентов доступа к данным. Веб-страница может вызывать методы этого компонента доступа к данным, чтобы получать данные текущего пользователя и затем сохранять любые изменения в них. Этот подход по-прежнему имеет смысл во многих сценариях. Однако в ASP.NET 2.0 появилось другое средство, называемое профилями, которое в ASP.NET 4 осталось неизменным. Когда используются профили, ASP.NET автоматически управляет извлечением специфичных для пользователя данных, обращаясь за ними к источнику данных заднего плана (обычно - к базе данных).

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

Одним из наиболее существенных отличий между профилями и другими типами управления состоянием является то, что профили предназначены для постоянного хранения информации с использованием источников данных заднего плана, таких как база данных. Большинство других типов управления состоянием предназначено для поддержки информации для последовательности запросов, поступающих за относительно короткое время (вроде непостоянных cookie-наборов и состояния представления), или для передачи информации от одной страницы к другой (такой как межстраничная отправка и строки запросов). Если нужно хранить информацию более длительное время в базе данных, то профили предоставляют для этого удобную модель, которая управляет хранением и извлечением информации.

Производительность профилей

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

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

С точки зрения производительности профили лучше работают, когда удовлетворяются следующие условия:

1. Есть относительно немного страниц, которые обращаются к данным профиля.

2. Сохраняется небольшой объем данных.

Хуже они работают при таких условиях:

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

2. Сохраняются большие объемы данных. Особенно низкая эффективность будет, когда необходимо использовать лишь некоторые из запрошенных данных (поскольку модель профилей всегда извлекает блок данных профиля целиком).

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

Сравнение профилей и специальных компонентов данных

Профили - естественный конкурент специальных компонентов данных, вроде тех, которые строили в статье «Компонент доступа к данным». Ясно, что компоненты данных обладают большей гибкостью. Они позволяют не только поддерживать специфичную для пользователя информацию, но также сохраняют информацию и другого рода, а также позволяют решать сложные бизнес-задачи.

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

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

Шифрование

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

Проверка достоверности

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

Если информация профиля используется на странице, она всегда извлекается из базы данных. Информацию из профиля нельзя хранить в памяти. Хотя можно скопировать информацию профиля в кэш, это сильно затруднит ее отслеживание.

Диагностика

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

 

 

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

Это классы, в которых содержатся стандартные HTML-элементы. За исключением атрибута runat="server" объявление серверных элементов управления HTML ничем не отличается от объявления других элементов управления. Двумя наиболее яркими представителями серверных элементов управления являются HtmlAnchor и HtmlSelect

Веб-элементы управления

Эти классы дублируют функции базовых HTML-элементов, но обладают более согласованным и значащим набором свойств и методов, которые упрощают их объявление и доступ к ним. В качестве примеров можно назвать элементы управления HyperLink, ListBox и Button. Более того, несколько других типов элементов управления ASP. часто считаются особыми типами веб-элементов управления. В Visual Studio вы найдете базовые элементы управления на вкладке Standard в окне Многофункциональные элементы управления

Эти усовершенствованные элементы управления могут генерировать большой объем HTML-разметки и даже клиентский JavaScript-код для создания интерфейса. В качестве примеров можно назвать элементы управления Calendar, AdRotator и TreeView. В Visual Studio многие многофункциональные элементы управления доступны на вкладке Standard в окне Toolbox.