69065

Основи технології ASP.NET

Лекция

Информатика, кибернетика и программирование

Принципи розробки користувацького інтерфейсу Інтернет-застосувань. Питання побудови користувацького інтерфейсу є одними з найважливіших у процесі розробки застосування. У разі розробки Веб-застосування, вони є особливо актуальними, оскільки процес створення користувацького інтерфейсу...

Украинкский

2014-09-29

604 KB

7 чел.

Лекція №9

Основи технології ASP.NET (частина 2)

Принципи розробки користувацького інтерфейсу Інтернет-застосувань. Питання побудови користувацького інтерфейсу є одними з найважливіших у процесі розробки застосування. У разі розробки Веб-застосування, вони є особливо актуальними, оскільки процес створення користувацького інтерфейсу тут має ряд істотних відмінностей від традиційних Windows-застосувань. При побудові Веб-застосування необхідно враховувати той факт, що його інтерфейс відображається у вікні браузера, а отже обмежений його можливостями.

Розробку користувацького інтерфейсу Веб-застосування можна робити як за допомогою редагування вихідного коду сторінки, так і з використанням вбудованого у Visual Studio візуального редактора. Найбільш ефективним способом є використання комбінованого методу, при якому в деяких режимах редагування доцільно користуватися візуальними засобами, у інших же випадках – засобами редагування вихідного коду.

Основною складністю при розробці інтерфейсу Веб-застосування є позиціонування його елементів. Існує чотири основні режими розміщення елементів керування Веб-сторінки:

  •  абсолютне позиціонування (absolutely positioned) – дозволяє розташовувати елементи саме там, куди їх поміщає розробник. При цьому елементи керування мають абсолютне положення на сторінці;
  •  відносне позиціонування (relatively positioned) – дуже схоже на абсолютне з тією різницею, що позиція елемента задається щодо елемента, який має статичне розташування на сторінці;
  •  статичне позиціонування (statically positioned) – при якому положення елементів керування визначається щодо інших елементів керування, розміщених на сторінці. При цьому усі елементи розташовуються послідовно один за одним;
  •  без заданого атрибуту позиціонування (no positioning attribute) – при якому редактором видаляється будь-яка інформація щодо позиціонування елемента керування. При цьому використовується статичне позиціонування.

Статичне позиціонування рекомендується використовувати у випадку, коли розташований на сторінці текст чергується з елементами керування.

При використанні абсолютного і відносного позиціонування Visual Studio додає спеціальні атрибути, що задають положення елемента. У наступному прикладі показаний фрагмент коду HTML, в якому описується розташування трьох кнопок з різними атрибутами позиціонування:

<asp:Button ID="Button2" runat="server" Style="z-index: 100; left: 436px; position: absolute; top: 187px" Text="Button1" />

<asp:Button ID="Button3" runat="server" Style="left: 245px; position: relative; top: 266px" Text="Button2" />

<asp:Button ID="Button4" runat="server" Style="position: static" Text="Button3" />

У цьому прикладі для елемента Button1 використовувалося абсолютне позиціонування, для Button2 – відносне, Button3 – статичне.

Керування станом. Колекція ViewState, об'єкти Session і Application

На попередній лекції розглядалися деякі складнощі, що виникають у процесі розробки Web-застосування. Зокрема, говорилося про те, що значення усіх даних, введених в елементи керування, після передачі клієнтові знищуються, оскільки знищується сама сторінка, що містить ці елементи керування. Для того, щоб зберігати значення елементів керування між зверненнями до сторінки застосування, можна використати декілька механізмів:

  •  стан перегляду або стан виду ViewState;
  •  рядок запиту; 
  •  cookie;
  •  стан сеансу (Session).

Колекція ViewState. Стан виду вирішує проблему, що виникає через відсутність підтримки стану у HTTP – втрату змін.

Кожного разу, коли сторінка відправляється назад, сервер отримує всю інформацію, введену користувачем у будь-якому елементі керування <input> дескриптора <form>. Потім ASP.NET завантажує веб-сторінку в її початковому стані (на підставі її компонування і певних налаштувань за промовчанням) і налаштовує сторінку у відповідності з цією новою інформацією. Проблема полягає в тому, що в динамічній Web-формі код може внести набагато більше змін. Наприклад, можна програмно змінити колір заголовка, модифікувати фрагмент статичного тексту, приховати або відобразити панель елементів керування або навіть пов'язати цілу таблицю даних з сіткою. Всі ці дії змінюють сторінку у порівнянні з її вихідним станом. Однак жодне з них не відображається в повертаних даних форми. Це означає, що інформація буде губитися після кожної зворотного відсилання. Зазвичай відсутність станів компенсується використанням простих наборів, cookie-наборів, заснованих на сеансах, і різних інших обхідних шляхів. Всі ці механізми вимагають застосування спеціальних (і іноді вельми ретельних) вимірювань.

З метою зняття цього обмеження у ASP.NET розроблений свій власний інтегрований механізм перетворення станів у послідовну форму (серіалізація станів). По суті, як тільки виконання коду сторінки завершується (перед генерацією та відправкою клієнтові остаточного HTML), ASP.NET досліджує властивості всіх елементів керування цієї сторінки.

Якщо деяка з властивостей змінювалася, ASP.NET зберігає цю інформацію в колекції ім'я-значення. Нарешті, ASP.NET серіалізує всю зібрану інформацію у рядок Base64. (Рядок Base64 забезпечує відсутність спецсимволів, неприпустимих в HTML.) Остаточний рядок вставляється у розділ сторінки <form> як нове приховане поле.

При зворотньому відсиланні сторінки ASP.NET виконує наступні дії:

1. Повторно створює сторінку і об'єкти елементів керування на основі правил за промовчанням. Тому сторінка знаходиться в тому ж стані, в якому була при першому запиті.

2. Виконує десеріалізацію інформації про стан і оновлює всі елементи керування. В результаті сторінка повертається у стан, в якому перебувала перед останньою відправкою клієнтові.

3. Наостанок здійснюється налаштування сторінки у відповідності з відправленими даними форми. Наприклад, якщо користувач ввів новий текст у текстовому полі або ж зробив новий вибір у вікні списку, ця інформація розміститься у колекції форми і буде використана ASP.NET для підгонки відповідних елементів керування. Після цього сторінка відображає поточний стан при її перегляді користувачем.

4. Тепер у дію вступає код обробки подій. ASP.NET генерує відповідні події, і код може реагувати зміною сторінки, переміщенням на нову сторінку або ж виконанням якоїсь іншої операції.

Використання стану виду є прекрасним рішенням, оскільки серверні ресурси можуть звільнятися після кожного запиту, допускаючи масштабованість сотень або тисяч запитів без уповільнення роботи сервера. Однак за все доводиться платити. Зберігання стану виду на сторінці збільшує її розміри. Це надає подвійний вплив на клієнт, оскільки йому необхідно не тільки отримати сторінку великих розмірів, але й повернути приховані дані про стан виду серверу з наступною зворотною відправкою. Тому багато часу йде на отримання і відправку сторінки. Для простих сторінок ці витрати мінімальні, але при налаштуванні складних елементів керування з великою кількістю даних на зразок GridView інформація про стан виду може істотно збільшитися. У таких випадках можна відключити стан виду для елемента керування шляхом установки його властивості EnableViewState рівною false. Однак у такому разі доведеться повторно ініціалізувати елемент керування при кожній зворотної відправки.

На замітку! Навіть при установці EnableViewState рівним false елемент керування все ще може намагатися зберегти меншу кількість інформації про стан виду, яку він "вважає" критичною для належного функціонування. Ця привілейована інформація про стан виду відома як стан елемента керування (control state), та заборонити її не можна. Проте у добре розробленому елементі керування розмір, необхідний для стану елемента керування, буде значно менший за розмір всього стану виду. Стан виду є новим в ASP.NET 2.0.

ASP.NET застосовує стан виду тільки до властивостей сторінок і елементів керування. ASP.NET не виконує ці ж дії із змінними екземплярів та іншими даними, які ви можете використовувати.

На рис. показаний механізм наскрізних запитів сторінок, що об'єднує всі ці концепції.

На замітку! Для успішного програмування в ASP.NET слід пам'ятати, що Web-форма повторно створюється в кожному повному циклі відправки. Вона не залишається в пам'яті довше, ніж йде часу на обробку окремого запиту.

Рис. Запити сторінок ASP.NET

Аналіз стану виду. Якщо переглянути згенерований HTML-код для сторінки ASP.NET, то можна побачити приховане поле введення з інформацією про стан виду. У наведеному на слайді прикладі демонструється сторінка, яка використовує простий Web-елементи керування кнопка та Label, яке містить текст " Hello, world!".

<html>

<head runat="server">

  <title>Hello World Page</title>

</head>

<form name="Form1" method="post" action="WebForm1.aspx" id="Form1">

  <div>

    <input type="hidden" nаmе="__VIEWSTATE" value="/wEPDwUKLTE2MjY5MTY1NQ9kFgICAw9kFgICAQ8PFgIeBFRleHQFDEhlbGxvIFdvcmxkIWRkZPsbiNOyNAufEt7OvNIbVYcGWHqf" /> 

  </div>

  <div>

    <input type="submit" name="Button1" value="Button" id="Button1" />

    <span id="lbl">Hello world!</span>

  </div>

</form>

</html>

Рядок стану виду не є читабельним, він виглядає як послідовність випадкових символів. Дані ViewState зберігаються у прихованих полях сторінки у форматі Base64, проте їх легко можна перетворити у масив байт, що представляють символи ASCII. Для цього досить використати функцію FromBase64String. Нижче, показаний фрагмент коду, який виконує цю роботу і записує декодувану інформацію на веб-сторінку:

       string viewStateString = "/wEPDwUKLTE2MjY5MTY1NQ9kFgICAw9kFgICAQ8PFgIeBFRleHQFDEhlbGxvIFdvcmxkIWRkZPsbiNOyNAufEt7OvNIbVYcGWHqf";

       byte[] stringBytes = Convert.FromBase64String(viewStateString);

       

       // Деcериализация и отображение строки.

       string decodedViewState = System.Text.Encoding.ASCII.GetString(stringBytes);

       Label1.Text = decodedViewState;

Ha Web-сторінці можна побачити наступне:

Як видно з прикладу, текст елемента керування виразно видно (разом з деякими символами, що не відображаються). Це означає, що в своїй реалізації за промовчанням стан виду не є підходящим місцем для зберігання чутливої інформації, яка має бути невидимою для клієнта  такі дані повинні залишатися на сервері. Більш того, не слід приймати рішення на підставі стану виду, які можуть скомпрометувати застосування, якщо клієнт втрутиться в дані стану виду.

Стан виду або перегляду ViewState. Передусім, необхідно розглянути можливість застосування стану виду (ViewState). Його доцільно використовувати у тому випадку, якщо необхідно організувати зберігання даних у межах однієї сторінки. Усі елементи керування використовують стан виду за промовчанням для збереження значень властивостей між операціями зворотнього відсилання даних. Тут же можливо організувати зберігання своїх власних даних, що складаються з простих типів і спеціальних об'єктів.

Стан виду організований за принципом колекції, яка, у свою чергу, має тип словника. Це означає, що дані зберігаються у форматі "ім'я-значення". Кожен елемент при цьому індексується за допомогою унікального строкового імені. У наступному прикладі у колекцію ViewState додається елемент з ім'ям Name, якому присвоюється значення "Іван":

       ViewState["Name"] = "Іван";

       ViewState["CurrentPage"] = 3;

При цьому якщо у колекції до цього не існувало елементу з ім'ям Name, то він додається, якщо ж такий елемент був, його значення замінюється на нове.

Для витягання елементу з колекції слід використати ім'я елементу. Крім того, оскільки колекція ViewState дозволяє зберігати не лише дані, що складаються з простих типів, але й спеціальні об'єкти (у загальному випадку – будь-які об'єкти), для отримання значення елементу необхідно перетворити його тип до того, який витягується. У наступному прикладі отримується значення елементу Name, яке потім перетворюється у рядок:

       string name;

       if (ViewState["Name"] != null)

           name = (string)ViewState["Name"];

Перевірка на наявність елементу колекції потрібна, оскільки при зверненні до неіснуючого елемента колекції виникає виключення NullReferenceException.

Збереження об'єктів в стані виду. У стані виду можна зберігати свої власні об'єкти, причому так само легко, як числові і рядкові типи. Однак щоб елемент був збережений у стані виду, ASP.NET повинен бути здатний перетворити його в потік байтів для того, щоб додати його в приховане поле для введення даних на сторінці. Цей процес називається серіалізацією. Якщо об'єкти не піддаються серіалізації (а за промовчанням це саме так), при спробі помістити їх в стан виду, з'явиться повідомлення про помилку.

Щоб зробити об'єкти придатними для серіалізації, слід просто додати перед оголошенням відповідного класу атрибут Serializable. Наприклад, нижче показаний надзвичайно простий клас BookPage:

[Serializable]

public class BookPage

{

  public int PageNum;

  public string Text;

  

  public Customer(int pageNum, string text)

  {

     PageNum = pageNum;

     Text = text;

  }

}

Оскільки клас BookPage помічений як придатний для серіалізації/такий, що не піддається серіалізації, він може бути збережений в стані виду:

       BookPage page = new BookPage(3, "Понеділок починається в суботу");

       ViewState["CurrentPage"] = page;

Не забувайте про те, що коли використовуються спеціальні об'єкти, при витяганні зі стану виду дані обов'язково повинні приводитися до якого-небудь типу:

       cust = (BookPage)ViewState["CurrentPage"];

Щоб клас піддавався серіалізациі, він повинен відповідати наступним вимогам:

  •  він повинен мати атрибут Serializable;
  •  всі породжувані від нього класи теж повинні мати атрибут Serializable;
  •  всі індивідуальні змінні цього класу повинні мати типи даних, що піддаються серіалізації, а типи даних, що не піддаються серіалізації, повинні супроводжуватися атрибутом NonSerialized (під час процесу серіалізациі вони будуть просто ігноруватися).

Оцінювання переваг використання стану виду. Застосування стану виду є ідеальним варіантом, тому що не передбачає використання ресурсів пам'яті сервера і появи випадкових обмежень (типу таймауту). Але є деякі ситуації, коли стан виду краще не застосовувати:

  •  Коли необхідно зберегти критично важливі дані, можливість зміни користувачем яких повинна бути повністю виключена (наприклад, кмітливий користувач міг би змінити дані стану виду у запиті на зворотню відправку даних). У такому випадку, краще використовувати стан сеансу.
  •  Коли необхідно зберегти інформацію, яка буде використовуватися кількома сторінками. У такому випадку більше підійде стан сеансу, cookie-набори або рядок запиту.
  •  Коли необхідно зберегти надзвичайно великий обсяг інформації і не хочеться, щоб це вплинуло на швидкість передачі даних сторінки. У такому випадку можливо краще використовувати базу даних або стан сеансу.

Щоб підвищити швидкість передачі даних на сторінці, стан виду, якщо він не використовується, краще відключити. Хоча відключити стан виду можна як на рівні застосування, так і на рівні сторінки, найбільш правильний варіант – відключити його на рівні елемента керування. Елемент керування не потребує стану виду у трьох наступних випадках:

  •  Коли цей елемент керування ніколи не змінюється. Наприклад, кнопка зі статичним текстом не потребує стані перегляду.
  •  Коли цей елемент керування заново заповнюється даними після кожної відправки даних. Наприклад, елемент керування типу Label, що відображає поточний час, значення якого встановлюється в обробнику подій Page.Load, не потребує стані виду.
  •  Коли цей елемент керування являє собою елемент керування для введення даними і змінюється тільки після того, як користувач виконає відповідні дії. Після кожної відправки даних ASP.NET буде заповнювати такі елементи керування даними, використовуючи введені у формі значення. Це означає, що текст у текстовому полі або вибраний елемент у полі зі списком не будуть втрачатися, навіть якщо стан виду не використовується.

Щоб відключити стан виду для деякого одного елемента керування, необхідно встановити для властивості EnableViewState цього елемента керування значення false. Щоб відключити стан виду для всієї сторінки і всіх елементів керування, що на ній відображаються, необхідно встановити значення false для властивості EnableViewState цієї сторінки або використати в директиві Page атрибут EnableViewState, як показано нижче:

<%@ Page Language="c#" EnableViewState="false" ... %>

Навіть якщо стан виду буде відключено для всієї сторінки, все одно буде видно прихований дескриптор стану виду з невеликою кількістю інформації. Це пов'язано з тим, що ASP.NET завжди зберігає як мінімум ієрархію елементів керування для сторінки, навіть якщо стан виду було відключено. Тому видалити цей останній невеликий фрагмент даних ніяк не вийде.

Використання рядка запиту. Одним з найсерйозніших обмежень стану перегляду є те, що воно працює тільки на одній сторінці. Якщо користувач переходить на іншу сторінку, збережена у ньому інформація втрачається. Існує кілька способів передачі інформації від однієї сторінки до іншої та від одного застосування до іншого, тому, який з них вибрати, залежить від наявних вимог.

Найбільш поширений підхід – передавати інформацію за допомогою рядка запиту в URL-адресі. Саме цей підхід часто застосовується у пошукових службах. Наприклад, ось як виглядають URL найбільш популярних пошукових систем при пошуку рядка «ASP.NET»:

Пошукова система Яндекс http://yandex.ua/yandsearch?text=ASP.NET&tld=ua&lr=143

Пошукова система Rambler http://nova.rambler.ru/search?query=ASP.NET

Пошукова система Google https://www.google.com.ua/search?hl=uk&biw=1120&bih=522&noj=1&sclient=psy-ab&q=ASP.NET&oq=ASP.NET&gs_l=serp.12...0.0.0.1266.0.0.0.0.0.0.0.0..0.0...0.0...1c.DUfOHoJVujs

З наведений прикладів видно, що ключові слова, з яких складається запит, вказані у рядку URL після знака питання. Отже рядок запиту – це та частина URL-адреси, яка знаходиться після знаку питання. Таким чином можна організувати передачу значень параметрів прямо у рядку запиту. Перевага такого підходу полягає у тому, що рядок запиту простий за своєю структурою і не викликає навантаження на сервер, – за допомогою такого механізму можна легко переносити інформацію з однієї сторінки на іншу. Недолік цього підходу полягає у тому, що за допомогою рядка запиту можна передавати тільки інформацію у вигляді простих рядків, що містять символи, які допускається використовувати в URL-адресі.

Для передачі інформації у рядку запиту, її (інформацію) необхідно помістити в URL-адресу сторінки, до якої повинен відбутися перехід. Це можна зробити, використовуючи елемент керування HyperLink, або скориставшись оператором Response.Redirect().

Наприклад, для того щоб перейти на сторінку Default6.aspx і передати у рядку запиту змінні ім'я користувача та призвище користувача, необхідно виконати наступний код:

   protected void Page_Load(object sender, EventArgs e)

   {

       String FirstName = "Іван";

       String LastName = "Іванов";

       Response.Redirect("login.aspx?username=" + FirstName + " " + LastName);

   }

Для передачі декількох параметрів у рядку запиту параметри розділяються знаком амперсанд – "&". З урахуванням цього попередній приклад можна переробити так, щоб ім'я та прізвище користувача передавалися окремо. Для цього змінимо рядок Response.Redirect наступним чином:

       Response.Redirect("Default6.aspx?firstname=" + FirstName + "&lastname=" + LastName);

Для вилучення рядка запиту слід використовувати метод QueryString об'єкта Request. Для отримання значень параметрів, що передаються в попередніх прикладах, потрібно застосовувати наступний код:

       string FN = Request.QueryString["firstname"];

       string LN = Request.QueryString["lastname"];

Варто звернути увагу на те, що інформація завжди витягується у вигляді рядка, яка потім може бути перетворена в який-небудь інший простий тип даних. Значення в колекції QueryString індексуються іменем змінної.

При використанні рядка запиту слід пам'ятати, що він завжди передається у відкритому вигляді, тому є дуже вразливім.

Перевагою рядка запиту є те, що цей спосіб є простим і не покладає ніякого навантаження на сервер. На відміну від пересилання даних між сторінками, рядок запиту може переносити одну й ту ж інформацію зі сторінки на сторінку. Однак він має кілька обмежень:

  •  може передавати інформацію лише у вигляді простих рядків, які повинні містити припустимі для використання в URL-адресі символи;
  •  інформація, що передається за допомогою рядка запиту, візуально доступна для користувача і будь-якої іншої людини,  що працює в Інтернеті;
  •  ініціативний користувач може змінити рядок запиту і надати нові значення, які програма ніяк не очікує отримати і від яких вона не має захисту;
  •  багато браузерів мають обмеження щодо довжини URL-адреси (яка, як правило, не повинна перевищувати 1-2 КБ), тому у рядок запиту можна помістити велику кількість інформації, і все одно доведеться виконувати перевірку на сумісність з більшістю браузерів.

І все-таки додавання інформації у рядок запиту є корисною технологією. Вона особливо підходить для застосувань баз даних, в яких користувачеві відображається список елементів, що відповідають записам у базі даних (наприклад, список продуктів): користувач вибирає елемент, після чого він перенаправляється на іншу сторінку, що містить детальну інформацію про обраний елемент. Один з найпростіших способів реалізувати таку схему – це змусити першу сторінку відправити ідентифікатор елементу другій сторінці. Друга сторінка потім шукає цей елемент у БД і відображає детальну інформацію про нього. Ця технологія дуже частина застосовується на сайтах електронної комерції, таких як Amazon.com.

Файли сookie (сookie-набори). Спеціальні cookie-набори – це ще один спосіб зберегти інформацію для наступного використання. Cookie-набори – це невеликі файли, які створюються на жорсткому диску клієнта (або, якщо вони є тимчасовими, у пам'яті Веб-браузера). Однією з переваг cookie-наборів є те, що вони працюють "прозоро" і користувач навіть не знає про те, що ця інформація повинна зберігатися. Вони також можуть використовуватися будь-якою сторінкою у застосуванні і навіть зберігатися між відвідуваннями, що передбачає дійсно довгострокове зберігання. Вони мають ті ж недоліки, що і рядки запитів: можуть зберігати тільки просту строкову інформацію, і користувач може отримати до них доступ і переглядати їх, відшукавши і відкривши відповідний файл. Ці фактори роблять їх не підходящим способом для зберігання складної або секретної інформації або просто великих обсягів даних.

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

Перш ніж використати cookie-набори, слід імпортувати простір імен System.NET, який дозволяє працювати з відповідними типами, як показано нижче:

using System.Net;

У використанні cookie-наборів в принципі немає нічого особливого складного. Колекцію Cookies надають два об'єкти: об'єкт Response та Request (обидва надаються через властивості об'єкта Page). Головне запам'ятати наступне: отримувати cookie-набори слід з об'єкта Request, а встановлювати їх слід за допомогою об'єкта Response.

Щоб встановити набір cookie, необхідно створити новий об'єкт System.Net.HttpCookie. Потім, слід заповнити його рядки інформацією і приєднати його до поточного Веб-відповіді, як показано нижче:

       // Створюється об’єкт cookie

       HttpCookie cookie = new HttpCookie("Language");

       // У ньому встановлюється значення

       cookie["LanguagePref"] = "English";

       // Об’єкт cookie додається до поточної Веб-відповіді

       Response.Cookies.Add(cookie);

Доданий таким чином cookie-набір буде зберігатися до тих пір, поки користувач не закриє вікно браузера, і буде відправлятися разом з кожним запитом. Щоб створити cookie-набір з більш довгим терміном зберігання, необхідно встановити дату закінчення терміну, як показано нижче:

       // Цей cookie буде залишатися дійним впродовже одного року

       cookie.Expires = DateTime.Now.AddYears(1);

Витягуються печива по імені за допомогою колекції Request.Cookies, як показано нижче:

       HttpCookie cookie = Request.Cookies["Language"];

       // Перевіряємо, чи знайдено cookie с таким именем

       string language;

       if (cookie != null)

       {

           language = cookie["LanguagePref"];

       }

Єдиний спосіб видалити cookie – це замінити його на cookie-набір, дата закінчення терміну зберігання якого вже пройшла. Наступний фрагмент коду демонструє, як це можна зробити:

       HttpCookie cookie = new HttpCookie("LanguagePref");

       cookie.Expires = DateTime.Now.AddDays(-1);

       Response.Cookies.Add(cookie);

Об'єкти Response та Request. Об'єкт Request містить інформацію, надіслану клієнтським браузером при запиті сторінки застосування. Властивості і методи Response дозволяють вирішувати завдання, пов'язані з аутентифікацією користувача, прийомом файлів від клієнта, визначенням типу браузера клієнта. Нижче наведено перелік властивостей і методів об'єкта Request.

Browser

Визначення номера версії браузера, який запитується, можливість підтримки ним файлів cookie та іншої службової інформації.

ClientCertificates

Аутентифікація клієнта.

Cookies

Отримання файлів Cookies від клієнта.

Files

Отримання файлів, переданих клієнтом.

InputStream

Читання і запис переданого запиту у вигляді неструктурованих даних.

Однією з найчастіше використовуваних можливостей об'єктів Request та Response є робота з файлами cookie. Файли cookie є одним з можливих механізмів збереження інформації під час роботи застосування для її подальшого використання. Ці файли зберігаються на жорсткому диску комп'ютера клієнта. Перевагою cookie є те, що вони працюють автоматично, користувач же при цьому навіть не знає, що якась інформація повинна бути збережена. Файли можуть зберігатися досить довго, що забезпечує можливість передачі інформації між відвідинами. Файли cookie можуть зберігати тільки просту строкову інформацію, а за рахунок того, що вони зберігаються на жорсткому диску комп'ютера, користувач може легко знайти відповідний файл і легко прочитати його вміст. Таким чином, cookie притаманні ті ж недоліки, що і рядку запиту, тому не рекомендується використовувати такого роду механізм для збереження складної або секретної інформації, а також за необхідності збереження великого обсягу даних.

Наприклад, для перевірки того, чи підтримує браузер клієнта файли cookie, необхідно виконати наступний код:

if (!IsPostBack)

  if (Request.Browser.Cookies) Response.Write("Ваш Браузер підтримує cookies");

   else                                          Response.Write("Ваш Браузер не підтримує cookies");

Для визначення типу браузера клієнта корисно скористатися властивістю Browser об'єкта Request. Наступний код виводить у вікні браузера його тип.

Response.Write ("Ваш браузер -" + Request.Browser.Browser);

Об'єкт Response необхідний для формування відгуку сервера на запит клієнта. За допомогою властивостей і методів Response можна управляти кешуванням відгуків перед відправкою клієнтові, змінювати вміст файлів cookie, читати і записувати неструктуровані дані, передані клієнтові.

Нижче наведено перелік властивостей і методів об'єкта Response.

Cashe

Визначає кешування відгуків перед відправленням їх клієнтові.

Cookies

Дозволяє задавати вміст файлів cookie, переданих клієнтові.

Output

Дозволяє читати і записувати неструктуровані дані, що повертаються клієнту у вигляді відгуку.

У наступному прикладі за наявності у браузері підтримки створюється cookie ім'я користувача, якому присвоюється значення "Іванов Іван".

protected void Page_Load(object sender, EventArgs e)

{

 if (!IsPostBack)

   if (Request.Browser.Cookies)

     if (Request.Cookies["UserName"] != null)

     {

       Session["User"] = Request.Cookies["UserName"].Value;

       Response.Write(Request.Cookies["UserName"].Value);

     }

     else

     {

     HttpCookie uname = new HttpCookie("UserName");

     uname.Value = "Іванов Іван";

     Response.Cookies.Add(uname);

     }

   else

     Response.Write("Ваш Браузер не підтримує cookies");

}

Cookie, що використовується у попередньому прикладі, буде зберігатися до тих пір, доки користувач не закриє вікно браузера, при цьому він буде відправлятися з кожним запитом. При необхідності збереження cookie протягом певного часу необхідно встановити дату закінчення терміну дії куки. У наступному прикладі cookie буде зберігатися протягом одного року.

uname.Expires=DateTime.Now.AddYears(1);

За необхідності видалення cookie потрібно встановити для нього "прострочену" дату закінчення терміну дії. Це можна зробити наступним чином:

uname.Expires=DateTime.Now.AddDays(-1);

Таблиця 1. Порівняння опцій для керування станом (частина 1)

Стан перегляду

Рядок запиту

Спеціальні cookie-набори

Допустимі типи даних

Всі піддаються серіалізації. NET-типи даних.

Обмежена кількість рядкових даних.

Рядкові дані.

Місце зберігання

Приховане поле на поточній Веб-сторінці.

Рядок URL-адреси у браузері.

Комп'ютер клієнта (у пам'яті або невеликому текстовому файлі, в залежності від терміну життя даного cookie-набору).

Термін життя

Зберігається постійно для відправки даних на одну сторінку.

Втрачається, коли користувач вводить нову URL-адресу або закриває вікно браузера, однак, може бути збережена у посиланнях.

Термін життя cookie-наборів визначається програмістом. Можуть використовуватися на декількох сторінках і зберігатися між відвідинами.

Контекст

Обмежується, але поточною сторінкою.

Обмежується цільової сторінкою.

Все ASP.NET-застосування цілком.

Безпека

За промовчанням є незахищеним, хоча можна скористатися директивами Page й примусово застосувати шифрування та хешування.

Доступна для перегляду і може бути змінена користувачем.

Ніяк не захищені і можуть змінюватися користувачем.

Складнощі, що впливають на продуктивність

Зберігання великої кількості інформації сповільнить процес передачі, але ніяк не відіб'ється на продуктивності сервера.

Ніяких, тому що кількість даних очевидна.

Ніяких, тому що кількість даних очевидна.

Звичайно застосовується для

Налаштування параметрів конкретної сторінки.

Відправки ідентифікаційного номера продукту зі сторінки каталогу на сторінку подробиць.

визначення персоналізованих уподобань на Веб-сайті.

Використання об’єкту Session. Стан сеансу (Session) – це найскладніша технологія керування станами. Вона дозволяє зберігати інформацію на одній сторінці і потім отримувати до неї доступ з іншої сторінки, а також підтримує об'єкти будь-якого типу, включаючи спеціальні, створювані самим розробником, типи даних. Найкраще те, що стан сеансу використовує той же заснований на колекціях синтаксис, що і стан виду. Єдина відмінність – ім'я вбудованої властивості сторінки, яке в даному випадку виглядає так: Session.

Кожен клієнт, який отримує доступ до застосування, має свій сеанс і свою окрему колекцію даних. Стан сеансу ідеально підходить для збереження таких даних, як елементи, що знаходяться у "кошику для покупок" користувача, коли він переходить з однієї сторінки на іншу. Але використання стану сеансу має деякі недоліки. Хоча воно вирішує багато з проблем, які виникають у разі застосування інших технологій керування станами, його використання змушує Веб-сервер зберігати додаткову інформацію у пам'яті. Ця необхідність використання додаткових ресурсів пам'яті сервера, нехай навіть у незначному обсязі, дуже швидко може досягнути загрозливого для продуктивності рівня, коли до сайту почнуть отримувати доступ сотні або тисячі клієнтів.

Архітектура сеансу. Управління сеансом не є частиною HTTP-стандарту. Тому ASP.NET доводиться виконувати деяку додаткову роботу, щоб відстежити інформацію сеансу і прив'язати її до відповідного відгуку/відповіді.

ASP.NET відстежує кожен сеанс за допомогою унікального 120-ти бітового ідентифікатора. ASP.NET використовує для генерації цього значення оригінальний алгоритм, який, згідно зі статистикою, гарантує, що число буде унікальним і досить випадковим для того, щоб зловмисник не зміг відтворити або вгадати ідентифікатор сеансу, яким буде користуватися даний клієнт. Цей ідентифікатор є єдиним фрагментом інформації, який передається між Веб-сервером і клієнтом. Коли клієнт надає ідентифікатор сеансу, ASP.NET відшукує відповідний сеанс, витягує з сервера станів "серіалізовані" дані, перетворює їх у "реальні" об'єкти і розташовує ці об'єкти у спеціальній колекції для того, щоб до них можна було отримати доступ у коді. Весь цей процес виконується автоматично.

Розглянемо, як ASP.NET зберігає дані в сесії. Коли ASP.NET обробляє HTTP-запит, той проходить через конвеєр різних модулів, які можуть реагувати на події застосування. Одним з модулів в цьому ланцюжку є модуль SessionStateModule (який знаходиться у просторі імен System.Web.SessionState). Цей модуль генерує ідентифікатор сеансу, витягує з зовнішніх постачальників стану дані сеансу і потім прив'язує ці дані до контекста викликів запиту. Він також зберігає дані стану сеансу, коли обробка сторінки завершується. Однак важливо розуміти, що модуль SessionStateModule фактично не зберігає дані сеансу. Замість цього, стан сеансу зберігається у зовнішніх компонентах, які називаються постачальниками стану. Весь цей процес показаний на наступному рисунку.

Стан сеансу є прикладом змінної архітектури у ASP.NET. Постачальником стану може бути будь-який клас, який реалізує інтерфейс IStateClientManager, а це означає, що спосіб роботи стану сеансу можна налаштувати, просто створивши (або купивши) новий .NET-компонент. ASP.NET включає три заготовлених постачальника стану, які дозволяють зберігати інформацію у процесі, в окремій службі та у базі даних SQL Server.

Постачальники стану сеансу. Параметр настроювання стану сеансу Mode дозволяє вказувати, який постачальник стану сеансу повинен використовуватися для зберігання даних стану сеансу між запитами. Допустимі значення описуються нижче.

Off. Установка значення Off призводить до відключення функції керування станом сеансу для всіх сторінок застосування. Це може трохи підвищити продуктивність Веб-сайтів, які не використовують стан сеансу.

InProc. Установка значення InProc нагадує підхід, який використовувався для зберігання стану сеансу у класичній версії ASP. Це значення вказує ASP.NET зберігати інформацію у поточному домені застосування, що забезпечує найкращу продуктивність, але найменший термін служби: якщо адміністратор перезапустить сервер, дані стану будуть втрачені.

Значення InProc використовується за промовчанням і підходить для більшості Веб-сайтів невеликого розміру. Однак у сценарії з групою серверів від нього не буде користі. Зробити так, щоб стан сеансу могли спільно використовувати відразу декілька серверів, можна тільки скориставшись зовнішньопроцесним постачальником або службою станів SQL Server. Ще одна причина, через яку установка значення InProc може бути небажаною, полягає у тому, що воно передбачає створення більш "тендітних/крихких" сеансів. У ASP.NET, домени застосувань нерідко створюються заново у відповідь на різні операції типу зміни конфігураційних налаштувань або оновлення сторінок, а також при досягненні певних порогових значень (незалежно від того, відбулася помилка чи ні). Якщо буде виявлено, що домен програми часто перезапускається, що призводить до передчасного завершення сеансів, можна спробувати усунути цей ефект, змінивши ті чи інші параметри моделі процесу, або скористатися іншим більш надійним постачальником стану сеансу.

Перш ніж використовувати зовнішньопроцесну модель (StateServer) або службу станів SQL Server, доведеться взяти до уваги наступні моменти:

  •  Якщо вибирається режим StateServer або SqlServer, об'єкти, що зберігаються у стані сеансу, повинні допускати серіалізацію, інакше ASP.NET не зможе передавати їх службі станів або зберігати у БД.
  •  Якщо ASP.NET обслуговує група Веб-серверів, доведеться виконати деякі додаткові конфігураційні кроки для гарантування того, що всі Веб-сервери будуть працювати синхронно. Інакше не виключено, що один сервер буде кодувати інформацію не так, як інший, а це, безсумнівно, призведе до появи проблем, якщо під час сеансу користувач перенаправлятиметься від одного сервера до іншого (рішенням цієї проблеми є зміна розділу <machineKey> файлу machine.config так, щоб він був однаковим на всіх серверах).
  •  Якщо не використовується внутрішньопроцесний постачальник стану, подія SessionStateModule.End не буде ініціюватися, і всі обробники цієї події у файлі global.asax або HTTP-модулі будуть ігноруватися.

StateServer. У разі встановлення цього значення, ASP.NET буде використовувати для управління станом окрему службу Windows. Навіть при запуску на тому ж самому Веб-сервері ця служба буде завантажуватися за межами основного процесу ASP.NET, що забезпечує для неї базовий рівень захисту, коли виникає необхідність перезапустити процес ASP.NET. Недоліком такого підходу є те, що через те, що дані стану передаються між двома процесами, збільшується час затримки. Якщо доступ до даних сеансу отримується часто, і вони часто змінюються, це може сильно уповільнити роботу.

Вибравши режим StateServer, обов'язково слід вказати значення для параметра stateConnectionString. Цей рядок повідомляє TCP/IP-адресу комп'ютера, на якому запускається служба StateServer, і номер його порту (який визначається ASP.NET і який, як правило, не потрібно змінювати). Це дозволяє обслуговувати службу StateServer на іншому комп'ютері. Якщо не змінити значення цього параметра, буде використовуватися локальний сервер (адреса якого виглядає так: 127.0.0.1).

SqlServer. Це значення вказує ASP.NET використовувати для зберігання даних сеансу базу даних SQL Server, застосовуючи параметри, визначені в атрибуті sqlConnectionString. Такий спосіб керування станом є найзручнішим, але і найповільнішим. Щоб його можна було використовувати, на сервері повинна бути встановлена база даних SQL Server.

Установка значення для атрибуту sqlConnectionString виконується за схемою, подібною до тієї, що використовується для отримання доступу до даних ADO.NET. В цілому вказується джерело даних (тобто адресу сервера), ім’я користувача і пароль, якщо тільки не використовується інтегрована система безпеки SQL.

Зазвичай база даних стану завжди називається "ASPState". Тому рядок підключення у файлі web.config не відображає явно ім'я бази даних. Замість цього, вона просто відображає місце розташування сервера та тип аутентифікації, який буде використовуватися:

<SessionState sqlConnectionString = "Data Source = 127.0.0.1; Integrated Security = SSPI"... />

При бажанні використовувати іншу базу даних (з такою ж структурою), необхідно встановити для атрибута allowCustomSqlDatabase справжнє значення і переконатися у тому, що рядок підключення включає параметр Initial Catalog, який вказує ім'я бази даних, яку слід використовувати:

<SessionState allowCustomSqlDatabase = "помилкових" sqlConnectionString = "Data Source = 127.0.0.1; Integrated Security = SSPI; Initial Catalog = CustDatabase"... />

Вибравши режим SqlServer, також можна встановити значення для необов'язкового атрибута sqlCommandTimeout. Цей атрибут вказує максимальну кількість секунд, протягом яких потрібно очікувати відповідь від бази даних, перш ніж запит буде скасовано. За промовчанням йому присвоюється значення, що дорівнює 30 секунд.

Використання стану сеансу. Взаємодіяти зі станом сеансу можна використовуючи клас System.Web.SessionState.HttpSessionState, який на Веб-сторінці ASP.NET доступний у вигляді вбудованого об'єкта Session. Синтаксис для додавання елементів у цю колекцію і їх витягання виглядає практично так само, як і синтаксис, який використовується для додавання елементів у стан виду сторінки.

Наприклад, зберегти об'єкт DataSet у пам'яті сеансу можна наступним чином:

Session["ds"] = ds;

Після цього, його можна витягти за допомогою відповідної операції перетворення:

ds = (DataSet) Session["ds"];

Контекст стану сеансу охоплює усе застосування і є глобальним для поточного користувача. Стан сеансу втрачається у наступних випадках:

  •  якщо користувач закриває і заново запускає браузер;
  •  якщо користувач отримує доступ до тієї ж сторінки через інше вікно браузера при збереженні доступу до Веб-сторінки з вихідного вікна браузера (різні браузери поводяться по-різному у такій ситуації);
  •  якщо сеанс завершується через відсутність активності з боку користувача (за промовчанням сеанс автоматично завершується після 20 хвилин простою);
  •  якщо програміст завершує сеанс, викликаючи метод Session.Abandon().

У перших двох випадках, сеанс фактично залишається у пам'яті, тому що Веб-сервер не знає про те, що клієнт закрив або змінив вікно браузера. Сеанс буде знаходитися у пам'яті, залишаючись недоступним, до тих пір, поки, врешті-решт, не закінчиться термін його дії.

Об'єкт Session. Об'єкт Session призначений для реалізації механізму стану сеансу, використовуваного для зберігання будь-якого типу призначених для користувача даних, які необхідно зберігати між запитами Web-сторінок. Призначені для користувача дані при цьому зберігаються у форматі "ім'я-значення". Такий механізм, зокрема, можна застосовувати при створенні інтернет-магазину, де покупець перед купівлею складає товари у віртуальний кошик, який після завершення сеансу (переходу на іншу сторінку або завершення роботи з браузером) має бути видалений. Для збереження даних про вибрані товари можна скористатися об'єктом Session.

При підключенні користувача до застосування створюється окремий сеанс і окрема колекція даних. Такі можливості мають свою ціну – дані, що зберігаються в сесії, зберігаються в оперативній пам'яті сервера. Навіть при маленькому обсязі цих даних їх використання може загрожувати продуктивності додатка в тому випадку, якщо доступ до сайту почнуть отримувати сотні і тисячі клієнтів.

Робота зі станом сеансу практично аналогічна роботі зі станом виду, за винятком того, що замість ключового слова ViewState застосовується ключове слово Session. Наприклад, для збереження об'єкта user в пам'яті сеансу необхідно виконати наступний код:

Session["user"]=user;

Для відновлення збереженого об'єкта користувачеві необхідно скористатися наступним кодом:

user=(string)Session["user"];

Стан сеансу знищується в наступних випадках:

1. якщо користувач закриває браузер;

2. після закінчення 20 хвилин з моменту останньої активності користувача;

3. при явному завершенні сеансу з програмного коду за допомогою виклику методу Session.Abandon();

Об'єкт Application. Об'єкт Application багато в чому аналогічний об'єкту Session. Різниця полягає лише в тому, що дані, що зберігаються в ньому, глобальні для всього застосування. Це так званий стан застосування, доступ до даних якого може отримати будь-який клієнт.

Стан застосування схожий на стан сеансу, оскільки зберігає інформацію на сервері, дозволяє зберігати об'єкти такого ж типу і використовує формат "ім'я-значення" для зберігання даних.

За допомогою стану програми можна створити лічильник і відстежувати інформацію про те, скільки разів та чи інша дія виконувалася всіма клієнтами даного застосування.

Для цього можна скористатися наступним кодом:

   protected void Page_Load(object sender, EventArgs e)

   {

       int count;

       if (Application["HitsNumber"] == null)

       {

           Application["HitsNumber"] = 1;

           count = (int)Application["HitsNumber"];

           Label1.Text = count.ToString();

           return;

       }

       count = (int)Application["HitsNumber"];

       count++;

       Application["HitsNumber"] = count;

       Label1.Text = count.ToString();

   }

Час життя елементів стану застосування ніколи не закінчується – вони існують до тих пір, поки застосування або сервер не будуть перезапущені.

У сучасній практиці стан застосування застосовується вкрай рідко, оскільки не є ефективним. Так, попередній приклад не гарантує коректного відображення значення лічильника. Це відбувається в тому випадку, якщо до застосування одночасно звертаються кілька клієнтів. У цьому випадку кожен з них зчитує одне й те ж поточне значення стану застосування HitsNumber, потім збільшує його на одиницю і знову записує у стан застосування. Таким чином, всі одночасні підключення, скільки б їх не було, призводять до збільшення стану застосування лише на одиницю. Для того щоб уникнути цієї проблеми, можна застосувати методи Lock() та Unlock(), які дозволяють одночасно отримати доступ до колекції лише одному клієнту. Наприклад, таким чином:

   protected void Page_Load(object sender, EventArgs e)

   {

       int count;

       Application.Lock();

       if (Application["HitsNumber"] == null)

       {

           Application["HitsNumber"] = 1;

           count = (int)Application["HitsNumber"];

           Label1.Text = count.ToString();

           return;

       }

       count = (int)Application["HitsNumber"];

       count++;

       Application["HitsNumber"] = count;

       Application.UnLock();

       Label1.Text = count.ToString();

   }

Недоліком цього підходу є те, що всі клієнти, які запитують сторінку, повинні чекати, поки колекція застосуваня не звільниться. Це може призвести до затримок і значно знизити продуктивність програми. Ось чому рекомендується використовувати файл web.config для зберігання констант рівня застосування, а часто використовувану інформацію найкраще зберігати в кеші ASP.NET.

Таблиця. Порівняння опцій для керування станом (частина 2)

Стан сеансу (Session)

Стан застосування(Application)

Допустимі типи даних

Усі .NET-типи даних, що піддаються сериализации. Типи, що не піддаються серіалізації, підтримуються, якщо використовується внутрішноьпроцесна служба станів.

Усі .NET-типи даних.

Місцезнаходження сховища/Місце зберігання даних

У пам'яті сервера

У пам'яті сервера

Час життя

Закінчується по закінченні визначеного періоду часу (який, як правило, триває 20 хвилин, але може бути змінений глобально або програмно).

Збігається з терміном життя застосування (який зазвичай триває до перезавантаження сервера).

Контекст

Усе ASP.NET-застосування.

Усе ASP.NET-застосування. На відміну від більшості інших типів методів, дані застосування є глобальними для усіх користувачів.

Безпека

Є безпечним/захищеним, тому що дані ніколи не передаються клієнту. Однак піддається атакам типу перехоплення сеансу, якщо не використовується SSL.

Є дуже безпечним, тому що дані ніколи не передаються клієнту.

Складнощі, що впливають на продуктивність

Збереження великої кількості інформації може значно сповільнити роботу сервера, особливо у випадку, коли до нього підключається одночасно велика кількість користувачів, тому що для кожного користувача буде створюватися окрема копія даних сеансу.

Збереження великої кількості інформації може сповільнити роботу сервера, тому що термін життя цих даних ніколи не буде закінчуватися, і вони ніколи не будуть видалятися.

Застосовується для

Зберігання елементів у "кошику для покупок".

Зберігання глобальних даних будь-якого типу.

Висновки. Способи взаємодії програмного коду з інтерфейсними елементами керування ASP.NET аналогічні тим, що застосовуються при розробці класичних Windows-застосувань. При генерації HTML-коду сторінки ASP.NET елементи керування перетворяться у теги HTML. Елементи керування, що використовуються для відображення даних на веб-сторінці, можуть розміщуватися на сторінці як шляхом перетягування з панелі інструментів, так і динамічним способом в процесі роботи застосування. При цьому можливе створення обробників подій таких елементів керування з використанням делегатів.

Будь-які елементи керування, розміщені на сторінці, поміщаються у контейнер, роль якого виконує сторінка застосування, представлена в ASP.NET класом Page. За допомогою даного класу можна отримати доступ до великої кількості об'єктів, що використовуються для управління сторінками Web-застосування. Через специфіку роботи інтернет-застосувань існують певні складнощі в організації обробки інформації. Вони пов'язані з тим, що після генерації коду HTML і відправки його клієнту примірник форми, розташований на сервері, знищується, отже, знищуються і дані елементів керування, що містяться всередині цієї форми. Для того щоб зберігати значення елементів керування між зверненнями до сторінки, необхідно використовувати колекції ViewState, об'єкти Session або Application.

Існує кілька способів передачі інформації від однієї сторінки до іншої і від одного застосування до іншого. Одним з таких способів є використання рядка запиту.

Для обміну інформацією між браузером клієнта та сервером існують об'єкти Response та Request. Однією з найчастіше використовуваних можливостей цих об'єктів є робота з файлами cookie. Ці файли зберігаються на жорсткому диску клієнта і можуть задіюватися для збереження даних між сеансами роботи з Web-застосуванням. Однак через слабку захищеність інформації, що зберігається у файлах cookie, не рекомендується використовувати їх для зберігання складно структурованої або секретної інформації.

Використання MasterPage

Зазвичай, при створенні сторінок використовуються вже готові шаблони і компоненти, або ж вони створюються у процесі розробки Веб-сторінок застосування. Це пов'язано з тим, що сторінки Веб-застосування складають деяке ціле, об'єднане єдиними вимогами до оформлення, змісту, розташування елементів керування тощо. Таким чином, користувач потрапляє в деяке середовище, яке має бути максимально зручним для задоволення усіх його потреб.

Одним із засобів вирішення подібних завдань є майстер-сторінки (master pages). Вони реалізують просту модель створення шаблонів форм з можливістю їх повторного використання. Головна сторінка визначає зовнішній вигляд сторінок веб-вузла. Вона може містити будь-яке поєднання статичного тексту і елементів керування, а також один або декілька прототипів вмісту, які визначають, де відображатиметься динамічний вміст при відкритті сторінки.

Для реалізації цього механізму, в ASP.NET введені такі типи сторінок, як майстер-сторінки (master pages) і сторінки вмісту (content pages). Майстер сторінка є шаблоном сторінки, при цьому, вона може містити будь-які елементи, допустимі для звичайної сторінки, а також програмний код. Сторінка вмісту містить допустимі елементи керування, за допомогою яких визначає вміст, яким заповнюються спеціальні області майстер-сторінок. Кожна сторінка вмісту посилається на одну майстер-сторінку, від якої отримує елементи і їх розташування.

Зазвичай, майстер-сторінка містить фіксовані елементи, однакові для усіх сторінок, і заповнювач вмісту для іншої частини сторінки. Найбільш типовими фіксованими елементами є верхній і нижній колонтитули, панель навігації, панель меню тощо. Сторінка вмісту отримує від майстр-сторінки фіксовані елементи і надає додатковий вміст.

Схематична структура майстер-сторінки показана на рисунку.

Така структура характерна для дуже великої кількості Веб-сайтів. Зображені на рисунку верхній колонтитул, нижній колонтитул і панель навігації є загальними для усіх сторінок елементами, вміст яких є постійним і не міняється. Вміст сторінки – це та її частина, яка міняється залежно від дій користувача, саме в ній відображається корисна для користувача інформація, і саме тут розміщуватиметься область, в якій відображатиметься сторінка вмісту.

Для демонстрації можливостей майстер-сторінок розглянемо приклад створення простої майстер сторінки і сторінки вмісту.

Майстер сторінок створюється так само, як і звичайні сторінки в ASP.NET. Відмінність полягає в тому, що Веб-сторінки розпочинаються з директиви Page, а майстер сторінка – з директиви Master:

<%--Звичайна сторінка ASP.NET--%>

<%@ Page Title="" Language="C#" AutoEventWireup="true" 

       CodeFile="Default.aspx.cs" Inherits="_Default" %>

<%--Майстер-сторінка ASP.NET--%>

<%@ Master Language="C#" AutoEventWireup="true" 

       CodeFile="MainMasterPage.master.cs" Inherits="MainMasterPage" %>

Ще однією важливою відмінністю є те, що майстер сторінок повинен містити елемент керування ContentPlaceHolder, який не має особливих властивостей і призначений для визначення області, в яку сторінка вмісту може вставляти вміст. При створенні нової майстер-сторінки, елемент ContentPlaceHolder створюється за-промовчанням, хоча його можна видалити або додати ще один або декілька.

Додамо на сторінку таблицю, яка схематично відображатиме шаблон сайту, що складається з верхнього і нижнього колонтитулу, меню і основної області. Тому таблица, що додається на майстер-сторінку, міститиме три рядка і один стовпець, середній рядок таблиці поділятиметься на два стовпчика – Меню і Основна область. У другий стовпчик другого рядка слід додано елемент ContentPlaceHolder з іменем MainPlaceHolder, який визначатиме розміщення вмісту сторінки. На наступному рисунку показана створена майстер-сторінка.

Головна сторінка надає шаблон для вмісту. Вміст для головної сторінки визначається шляхом створення сторінки ASP.NET, яка пов'язана з головною сторінкою. Сторінка вмісту є спеціалізованою формою ASP.NET, яка містить тільки вміст, який має бути об'єднаний з головною сторінкою. Додайте на сторінку вмісту текст і елементи керування, які необхідно відобразити, коли користувачі запрошують цю сторінку.

Створимо сторінку, засновану на вже розробленій майстер-сторінці. Для прикладу, візьмемо одну із сторінок, які розробляються у лабораторній роботі №2 і містять елементи керування GridView (або DetailView) та SqlDataSource. В якості сторінки вмісту використаємо сторінку Default2.aspx, додану до проекту Веб-застосування за промовчанням.

Сторінка вмісту не має звичайних елементів, що формують сторінку ASP.NET, таких як html, body або form. Замість цього додається тільки той вміст, який повинен відображатися на головній сторінці у створених областях прототипу вмісту. (Для того, щоб перетворити звичайну сторінку на сторінку вмісту, необхідно в якості значення властивості MasterPageFile сторінки, вказати ім'я майстер-сторінки, а також додати на сторінку елемент керування <asp: Content>.)

Початковий код сторінки Default2.aspx в результаті виконаних операцій, а також змінення значення атрибуту ContentPlaceHolderID на MainPlaceHolder виглядатиме таким чином:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" MasterPageFile="~/MasterPage.master" %>

<asp:Content ContentPlaceHolderID="MainPlaceHolder" ID="Content1" runat="server">

</asp:Content>

Вигляд форми у поданні Конструктор:

Результат роботи програми:


 

А также другие работы, которые могут Вас заинтересовать

34394. Промышленные комплексы. Проблемы их функционирования в современных условиях. Реструктуризация промышленности 34 KB
  Строительство основа строительного комплекса особенностями которого являются длительный период производства продукции и большие затраты трудовых материальных и финансовых ресурсов. Особое внимание при этом предусматривается уделять модернизации наукоемкого сектора промти экспортно ориентированным отраслям и импортозамещающим производствам созданию и развитию производств основанных на прогрессивных технологиях. Предусматриваются следующие важнейшие меропр: реформирование системы гос п п завершение приватизации малых п п и...
34395. Прогнозирование и планирование объема и структуры промышленного производства 33 KB
  На заключительном этапе формируются плановый объем и структура выпуска промышленной продукции с учетом спроса возможностей производства и обеспечения производственными ресурсами. Обосновывается и устанавливается заказ на поставку важнейших видов продукции для государственных нужд. Для прогнозирования спроса и объема производства конкретных видов продукции хорошие результаты дает метод Дельфи . Путем анкетного опроса группы ученых и специалистов по данной проблеме формируется информация по выпуску каждого вида продукции по годам которая...
34396. Сущность и содержание прогнозирования. Роль и характер прогнозов 44.5 KB
  Прогнозирование это процесс разработки прогноза построенный на вероятностном научно обоснованном суждении о перспективах развития объекта в будущем его возможном состоянии и альтернативных путях его достижения. Социальноэкономическое прогнозирование является способом предвидения представления о будущем обусловленном закономерностями общественного развития и действием разнообразных и разнонаправленных факторов в прогнозируемом периоде. В соответствии с Законом О государственном прогнозировании и программах социальноэкономического...
34397. Сущность планирования. Директивное, индикативное, стратегическое планирование, их характеристика 47 KB
  При формировании рыночных отношений в Республике Беларусь необходимо видение перспектив ее экономического и социального развития. Планирование это процесс принятия управленческого решения основанный на обработке исходной информации и включающий в себя определение и научную постановку целей средств и путей их достижения посредством сравнительной оценки альтернативных вариантов и выбора наиболее приемлемого из них в ожидаемых условиях развития. Суть планирования состоит не в разработке и доведении многочисленных показателей до...
34398. Предмет курса, его место в системе экономических наук 27 KB
  Пип – наука изучающая экие теории и законы применительно к конкретным условиям производства их специфические проявления в важнейших процессах прва закономерностях темпов и пропорциях с тем чтобы в результате этого изучения с учетом достижений НТП передового опыта обосновать объемы темпы и пропорции общественного производства в целях наиболее эффективного развития экономики. Задача курса состоит в рассмотрении комплекса теоретических методологических организационных вопросов пип экономики на современном этапе. Теория пип является...
34399. Исторический аспект развития прогнозирования и планирования 26 KB
  Экономическая мысль совершая поиск путей становления системы планирования испытывала колебания вступала в противоборство допуская ошибки и избавляясь от них под влиянием реальных явлений хозяйственной жизни. Рассмотрим становление и совершенствование прогнозирования и планирования в бывшем СССР и развитых зарубежных странах. Первый долгосрочный план который представляет интерес с точки зрения общей методологии планирования это план ГОЭЛРО государственный план электрификации России разработанный в 1920 г.
34400. Развитие и особенности ПИП в зарубежных странах (США, Япония, Франция и др.) 45.5 KB
  Для США характерно стратегическое планирование суть которого состоит в выборе главных приоритетов развития национальной экономики ведущую роль в реализации которых играет государство. Основным источником займов на цели разработки и освоения новой технологии является Японский банк развития. Направления стратегического развития разрабатываются в виде целевых государственных программ и сопровождаются комплексом различных финансовых льгот и преференций стимулирующих их реализацию. Она представляет собой модель будущего развития экономики...
34401. Научные основы методологии прогнозирования и планирования 30.5 KB
  Вторая является основой планирования и прогнозирования в странах с рыночной экономикой. Методология прогнозирования и планирования развития экономики определяет основные принципы подходы и методы проведения прогнозных и плановых расчетов раскрывает и характеризует логику формирования прогнозов планов и их осуществления. Принципы это основополагающие правила прогнозирования и планирования т.
34402. Система показателей планов-прогнозов 30.5 KB
  Нормативы показатели в относительном выражении. Лимиты ресурсные показатели представляющие предельно допустимую величину затрат ресурса для достижения установленных конечных результатов. Основными блоками показателей прогнозирования и планирования экономических и социальных процессов являются: показатели производства трудовых ресурсов основных и оборотных фондов капитальных вложений природных ресурсов научнотехнического прогресса финансов и денежного обращения социального развития и уровня жизни населения внешнеэкономических...