1. Asp.Net
Тема 1. Вступ до технології asp.Net
1.1. Архітектура і загальні концепції asp.Net
Розглянемо базові принципи функціонування та архітектури технології ASP.NET. Спочатку розглянемо схему роботи в мережі Internet, яку можна назвати «класичною», так як ця схема є історично першою. Основними елементами класичної схеми є браузер і веб-сервер. При взаємодії браузер і веб-сервер проходять наступні етапи:
1. Браузер формує запит до сервера, використовуючи протокол HTTP. Як правило, браузер запитує HTML-сторінку, тобто текстовий файл, що містить HTML-код.
2. Сервер аналізує запит браузера і витягує з локального джерела даних необхідний файл.
3. Сервер формує HTTP-відповідь, що включає необхідну інформацію, і відсилає його браузеру по протоколу HTTP.
4. Браузер виконує відображення сторінки.
Класична схема проста, але має істотний недолік - сторінки статичні, і їх вміст не може змінюватися динамічно залежно від запитів клієнта. В даний час подібний підхід не відповідає більшості інформаційних послуг, наданих за допомогою мережі Internet. Класичним прикладом є типовий Інтернет-магазин. Якщо користувач на сторінці визначає якусь умову фільтрації, то браузер повинен відобразити список товарів, наявних в даний момент в магазині , які задовольняють фільтру. Тобто все більшого поширення набувають технології, при використанні яких сторінки (цілком або частково) генеруються на сервері безпосередньо перед відправкою клієнту. Ці технології зазвичай містять в своїй назві словосполучення Server Pages - «серверні сторінки» (ASP, ASP.NET). Технологія «серверних сторінок» працює за схожими принципами:
• Для подання інформації на сайті використовуються не сторінки з HTML-кодом, а серверні сторінки спеціального синтаксису (який часто є HTML-подібним).
• При запиті серверної сторінки веб-сервер запускає окремий службовий процес, якому перенаправляється запит.
• У службовому процесі сторінка аналізується, і на її основі генерується новий об'єкт (об’єкт класу), який відповідає класу сторінці.
• Службовий процес виконує методи згенерованого об'єкта. Як правило, об'єкт має спеціальний метод, що генерує вихідний потік сторінки у вигляді HTML-коду.
• Сервер перехоплює вихідний потік сторінки, формує HTTP- відповідь і відсилає його браузеру.
• Браузер виконує відображення сторінки.
Рис. 1. Технологія серверних сторінок
1.2. Приклад aspx-сторінки. Структура сторінки
Розглянемо особливості технології серверних сторінок, стосовно до ASP.NET. Службовий процес ASP.NET заснований на керованому коді і виконується в Common Language Runtime. Серверній сторінці в ASP.NET відповідає якийсь .NET-клас. Це забезпечує можливості міжмовної взаємодії, використання готових бібліотек коду тощо. Серверна сторінка може містити «вкраплення» серверного коду, написані на деякій із мов - C #, VB.NET, J #.
ASP.NET представляє і підтримує концепцію фонового (або роздільного) коду (Code Behind). Ця концепція дозволяє розділити логіку і візуальне представлення. Відповідно до даної концепції клас сторінки успадковується від деякого базового класу, в якому розміщуються методи, що утворюють логіку виконання сторінки. Сама сторінка містить тільки опис візуальної частини (деякі візуальні компоненти і де розміщені та як налаштовані їх властивості).
Технологія ASP.NET також намагається перенести принципи, використовувані при написанні додатків Windows Forms, на web-програмування. Мова йде про програмування, заснованому на обробці подій. Окремий компонент сторінки ASP.NET, як правило, володіє набором деяких подій.
Хорошим прикладом є кнопка, у якої є подія On_Click. Для того щоб закодувати логіку сторінки, програміст пише обробники для відповідної події. Коли подія відбувається, інформація про нього пере силается від клієнта на сервер, де спрацьовує обробник події. Потім сторінка (вся або тільки її частину) знову пересилається клієнту.
Щоб сторінка зберігала свій стан між окремими циклами прийому-передачі, цей стан фіксується в спеціальному прихованому полі перед відправкою на сервер, а сервер відновлює стан сторінки перед відправкою клієнту. Даний технологічний прийом називається в ASP.NET підтримкою ViewState (відображуваного стану)
Будь-яка серверна сторінка ASP.NET являє собою текстовий файл з розширенням .aspx. Далі такі сторінки будуть для стислості називатися aspx-сторінками. Розглянемо приклад простої aspx-сторінки, яку розмістимо у файлі test.aspx:
<%@ Page Language="C#"%>
<script type="text/C#" runat="server">
int Sum(int i1, int i2)
{
return i1 + i2;
}
</script>
<html>
<head>
<title></title>
</head>
<body>
<p>Цифри: <% for (int i = 0; i < 10; i++) { Response.Write(string.Format("{0} ", i));};%></p>
<p>Число Pi: <% =Math.PI %></p>
<p>2+3=<% =Sum(2,3) %></p>
</body>
</html>
Для перегляду даної сторінки засобами Visual Studio потрібно натиснути клавішу F5. Вигляд сторінки в браузері показаний на рисунку 2.
Рис. 2. Страница, отображаемая в браузере
Розглянемо докладніше структуру сторінки. У будь-якій сторінці можна виділити кілька логічних секцій:
1. HTML-код. HTML-код не обробляється процесом ASP.NET спеціальним чином, а відразу пересилається клієнту. Виводом HTML-коду займається спеціальний внутрішній метод __Render__control() того класу, який відповідає сторінці. В нашому випадку фрагмент сторінки
<html>
<body>
буде виведений в методі __Render__control() так:
private __Render__control()
{
Response.Write("<html>\r\n<body>\r\n");
...
}
2. Директиви сторінки. Директиви використовуються для встановлення окремих параметрів сторінки, таких як мова програмування для коду сторінки або підключення простору імен. Директива починається з символа @, за яким слідує ім'я директиви і набір пар «атрибут = значення». Наприклад, наступна директива вказує на використання C # в якості мови програмування на сторінці:
<%@ Page Language="C#" %>
Директиви можуть розміщуватися в будь-якому місці сторінки, але поза HTML-елементами. Як правило, директиви поміщають на початку сторінки.
@Page
За допомогою директиви @Page встановлюються найважливіші параметри сторінки. Директива має багато атрибутів, основні із яких перераховані в еаступній таблиці.
|
Назва атрибута |
Можливі значения |
Опис |
|
AutoEventWireup |
True False |
Вказує, чи виконується автоматичне зв'язування подій сторінки з методами, що мають специфічні імена (наприклад, Page_Load) |
|
Buffer |
True False |
Дозволяє буферизацию відповіді сервера. При включеної буферизації вихідний потік сторінки спочатку записується в пам'ять на сервері, а відсилається клієнту повністю сформованим |
|
ClassName |
Ім’я класу |
Ім'я для класу сторінки. За замовчуванням ім'я файлу сторінки, в якому точка між ім'ям і розширенням aspx замінена символом підкреслення |
|
ContentType |
Допустимий MIME-тип |
Вказує на тип вмісту відповіді. Атрибут використовується, коли повертається значення, яке відрізняється від text/html (наприклад, відповідь сервера - зображення) |
|
Culture |
Ідентифікатор культури |
Ідентифікатор культури встановлює мову і формати запису дат, чисел і т. п. наприклад, ідентифікатор культури для американської англійської - en-US (використовується за замовчуванням) |
|
Description |
Будь-який текст |
Опис сторінки - ігнорується в ASP.NET |
|
EnableSessionState |
True False ReadOnly |
Показує, чи має сторінка доступ до стану сеансу (об'єкту Session). У разі ReadOnly стан сеансу доступний тільки для читання |
|
EnableViewState |
True False |
Чи підтримує сторінка збереження стану для серверних елементів управління |
|
ErrorPage |
Допустимий URL |
Сторінка для переадресації при виникненні необробленої помилки |
|
Inherits |
Ім’я класу (можливо з простором імен) |
Вказує простір імен (опційно) та ім'я класу, від якого буде успадковуватися клас сторінки. Атрибут використовується спільно з атрибутом Src |
|
Language |
Ім’я мови .NET |
Мова програмування, яка застосовується для блоків серверного та рендерного коду. Зазвичай використовуються значення VB і C #. Атрибут Language може бути записаний в серверному тезі <script>. ASP.NET підтримує тільки одну мову на сторінці |
|
ResponseEncoding |
Ім’я системи кодування символів |
Формат кодування тексту, що відправляється у відповідь. За замовчуванням - Unicode (UTF-8) |
|
Src |
Имя вмхідного файлу |
Шлях та ім'я файлу з вихідним кодом класу, спадкоємцем якого є сторінка. Використовується спільно з атрибутом Inherits |
|
Trace |
True False |
Вказує на необхідність виконувати трасування сторінки. Трасування полягає у виведенні в нижній частині сторінки різної додаткової інформації і може бути корисна при налагодженні |
|
TraceMode |
SortByTime SortByCategory |
При включеному трасуванні визначає порядок сортування повідомлень (за часом або за категорією) |
|
ValidateRequest |
True False |
Вказує, чи виконується перевірка запиту. Перевірка полягає в контролі всіх переданих даних на потенційно небезпечні значення, до яких віднесені код HTML і скриптів. Якщо небезпечні значення виявлені, генерується HttpRequestValidationException |
@Control
Дана директива має функціональність, схожу з директивою @Page, але використовується для елементів ASP.NET, які створюються користувачем (так звані елементи управління користувача). Атрибути, доступні в директиві @Control, утворюють підмножину атрибутів директиви @Page: AutoEventWireup, ClassName, Description, EnableViewState, Inherits, Language, Src.
@Import
Директива використовується для імпорту просторів імен для сторінки. це робить доступним на сторінці всі класи та інтерфейси з імпортованого простору. Приклад використання директиви:
<% @ Import Namespace = "System.Collections.Generic"%>
Одна директива @Import дозволяє імпортувати один простір імен, тому для імпортування декількох просторів треба відповідну кількість директив. Платформа .NET при роботі з ASP.NET автома- тично імпортує такі простори імен:
System
System.Web
System.Collections
System.Web.Caching
System.Collections.Specialized
System.Web.Security
System.Configuration
System.Web.SessionState
System.IO
System.Web.UI
System.Text
System.Web.UI.HtmlControls
System.Text.RegularExpressions
System.Web.UI.WebControls
@Implements
Директива @Implements дозволяє реалізувати на сторінці інтерфейс. При реалізації інтерфейсу ви повідомляєте, що сторінка буде підтримувати певні властивості, методи і події (аналогічно реалізації інтерфейсу в класі). У наступному прикладі вказано, що сторінка реалізує інтерфейс IPostBackEventHandler:
<% @ Implements Interface = "System.Web.UI.IPostBackEventHandler"%>
@Register
Дана директива використовується при додаванні на сторінку індивідуального серверного елемента управління для повідомлення компілятору інформації про цей елемент. Існують дві форми директиви @Register:
<%@ Register TagPrefix="tagprefix" TagName= "tagname" Src = "pathname"%>
<% @ Register TagPrefix = "tagprefix" Namespace = "namespace" Assembly = "assembly"%>
Перша форма використовується, коли серверний елемент представлений у вигляді вихідного тексту, друга - для посилання на простір імен відкомпільованих серверних елементів. Атрибут TagPrefix задає префікс для елементів, розроблених користувачем на сторінці. Наприклад, нехай задана наступна директива @Register:
<%@ Register TagPrefix="Ecommerce" TagName="Header" Src = "UserControls \ Header.ascx"%>
Тоді перед кожним екземпляром елементу Header на сторінці вказується префікс Ecommerce:
<Ecommerce: Header id = "Header" runat = "server" />
Атрибут TagName задає ім'я, яке буде вживатися для посилання на елемент управлянні користувачана сторінці. Атрибут Src визначає ім'я файлу з призначеним для користувача елементом. У разі використання другої форми діректі- виRegister, атрибути Namespace і Assembly визначають простір імен і збірку, що містить індивідуальний елемент:
<% @ Register TagPrefix = "Wrox" Namespace = "WroxControls" Assembly = "RatingMeter"%>
Аналогічно до першого випадку, для вказання на сторінці якогось елементу управління зі збірки RatingMeter необхідно буде вказати тег
<Wrox: імя_елемента>
@Assembly
Ця директива використовується для безпосереднього посилання на збірку, з тим щоб наявні в ній класи та інтерфейси стали доступні коду на сторінці. Можна передати ім'я відкомпільованої зборки
<% @ Assembly Name = "ім'я збірки"%>
або шлях до вихідного файлу, який компілюватиметься при компіляції сторінки:
<% @ Assembly Src = "шлях"%>
@Reference
Дана директива дозволяє динамічно відкомпілювати елемент управління користувача і помістити його в колекцію Controls сторінки або серверного елемента управління. Директива використовується у поєднанні з методом Page.LoadControl().
3. Блоки серверного коду. Це блоки, обрамлені тегом <script> із обов’язковим атрибутом зательным атрибутом runat="server":
<script runat="server">
string[] Data = {"Hello ", "world ", "from ", "ASP.NET"};
string getData(int i) {
return Data[i];
}
</script>
Блоки серверного коду транслюються в члени класу, відповідного сторінці. У наведеному прикладі клас буде містити поле-масив Data та метод getData ().
Відзначимо, що наявність блоків серверного коду на сторінці суперечить концепції Code Behinde. Відповідно до даної концепції код, пов'язаний зі сторінкою ницей, повинен бути поміщений в окремий клас, від якого успадковується клас сторінки.
4. Блоки рендерного кода. Блоки рендерного коду використовуються для генераціі потоку виводу. У нашому прикладі блоком рендерного коду є фрагмент
<% for (int i = 0; i < 4; i++) Response.Write(getData(i)); %>
При обробці на сервері блоки рендерного коду поміщаються безпосередньо в метод, який відповідає генеруванню HTML-коду сторрінки. Таким чином, метод __Render__control() буде містити наступний код:
private void __Render__control()
{ Response.Write("<html>\r\n<body>\r\n");
for (int i = 0; i < 4; i++) Response.Write(getData(i));
. . .
}
Якщо блок рендерного коду записується у формі <% = вираз%>, то в метод вставляється висновок обчисленого виразу (приклад виведення значення числа пі).
5. Елементи управління. Детально розглянемо їх пізніше.