4. Сценарії обробки запитів

Нижче описаний типовий сценарій взаємодії елементів Web-додатку один з одним і з клієнтом, що здійснює запитформи цього додатка (рис. 5.5).

Рисунок 5.5 – Типовий сценарій взаємодії елементів web-форми з користувачем

Як видно з рис. 5.5, при зверненні клієнта до Web-додатку, web-додаток запускається на сервері IIS. Запущенийдодаток формує відповідь (відгук). Для цього на сервері створюється екземпляр Web-форми, вона генерує HTML-текствідповіді, яка і передається браузеру клієнта. Відразу після цього примірник Web-форми знищується. Користувач,отримавши HTML-сторінку, згенеровану додатком, має можливість заповнювати різні поля форми (тестові поля, перемикачі і т. п.). Після заповнення всіх необхідних полів форми користувач ініціює відправлення даних, введених ним в сторінку, назад на сервер. Це відбувається за рахунок використання технології зворотного відсилання, яка викликається привиконанні певних дій (наприклад, натисканні на кнопку). Отримавши дані від користувача, сервер створює новий екземплярWeb-форми, заповнює його отриманими даними і обробляє всі необхідні події. Після закінчення обробки, сервер формуєHTML-код відповіді і відправляє його клієнту, а потім знищує екземпляр Web-форми. Більш детально описаний сценарійзображено на рис. 5.6 та 5.7.

Рисунок 5.6 – Сценарій взаємодії елементів web-додатку запитів при першому зверненні

 

Рисунок 5.7 – Сценарій взаємодії елементів web-додатку з клієнтом при запиті зворотної відправки

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

Такий принцип організації виконання Web-додатків добре підходить для масштабованих додатків з інтенсивним мережевим обміном. Однак у нього є і недоліки. Зокрема, виявляється неможливим зберігати дані, що належать формі, навіть протягом роботи користувача з додатком. Тобто, якщо ми захочемо створити якусь змінну, що зберігає, наприклад ідентифікатор замовлення, з яким ми зараз працюємо, зробити це буде неможливо, тому що форма після відправки клієнтові відразу ж знищується. Щоб обійти цей недолік, ASP.NET використовує спеціальний механізм для збереження даних, введених в елементи управління Web-форми. Згідно з цим принципом, в рамках кожного запиту на сервер відправляються всі дані, які були введені в елементи управління. При цьому, як уже згадувалося вище, на сервері виникає подія Page_Init, метою якої є створення Web-форми і її ініціалізація. У процесі ініціалізації в елементи управління створеної форми записуються передані від клієнта дані. Тепер ці дані стають доступні додатку за допомогою обробки подіїPage_Load, що виникає при кожному зверненні до сторінки.

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

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

Після цього ініціюється Page_Load. Більшість Web-сторінок використовують цю подію для виконання ініціалізації, наприклад, заповнення полів даними, установки початкових значень для елементів управління і т. д. Крім того, у процедурі обробки даної події можливе визначення того, чи була завантажена сторінка вперше чи звернення до неї здійснюється повторно в рамках технології зворотного відсилання, що сталося в результаті натиснення користувачем кнопки або іншого елемента керування, розміщеного на сторінці. В англійській термінології зворотне відсилання даних на сервер називаєтьсяpost back. Для визначення поточного стану сторінки необхідно перевірити властивість Page.IsPostBack, яка матиме значення false при першому запуску сторінки. Визначення першого чи повторного звернення до сторінки є важливим, тому що дозволяє проводити ініціалізацію тільки в тому випадку, коли запит до сторінки здійснюється вперше. Так, наприклад, при зворотному відсиланні даних на сервер не тільки немає необхідності проводити ініціалізацію, встановлюючи початкові значення елементів управління, але це навіть може бути помилкою, тому що ці елементи управління повинні отримати значення, передані їм від користувача.

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

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

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