Введення у 2
Використання кількох мов програмування
Microsoft .NET Framework та Visual Studio 2005 підтримує кілька мов програмування, таких як Visual Basic, Visual C#, Visual C++, Visual J#. Оскільки ці мови використовують єдине середовище виконання CLR (Common Language Runtime) і відповідають загальним стандартам CLS (Common Language Specification), то збірка, створена із застосуванням однієї з .NET мов, може бути використана в проекті, що розробляється іншою мовою програмування, також, ніби ця збірка і додаток були написані однією і тією ж мовою. З виходом Microsoft .NET Framework 2.0 стало можливо використовувати в тому самому проекті різні мови програмування. Те, що Web-додаток ASP.NET може бути написано кількома мовами програмування, дуже зручно, якщо вже є перевірені рішення однією мовою, а проект пишеться з використанням іншої мови, або, якщо в команді є розробники, які використовують різні мови програмування . Про те, як використовувати різні мови в одному проекті, можна прочитати в цій статті.
Технологія поділу коду
Але для підтримки редагування за допомогою Microsoft Visual Studio .NET в сторінці ASP.NET необхідно вказати клас, що відповідає даній сторінці і файл, в якому знаходиться код цього класу. Для цього директива Page перетворюється за допомогою ключових слів Codebenind та Inherits.
В ASP.NET 2.0 використовується інший механізм поділу коду. У директиві Page необхідно використовувати інші ключові слова: CodeFile і Inherits.
У цьому випадку код класу програмної логіки сторінки буде розміщений у файлі, вказаному в атрибуті CodeFile. Слід зазначити, що Visual Studio2005 використовує класи, що розділяються (partial classes).
Тому розробник може помістити код класу в декількох файлах, але подібне розосередження коду робить додаток вельми громіздким і важким у підтримці та розробці. Модель Code-Behind, що використовується в Visual Studio 2003, має кілька дуже істотних недоліків. Перш за все, використовуючи Visual Studio розробнику необхідно компілювати проект перед публікацією, оскільки ASP.NET компілює сторінки, лише якщо вказано атрибут Src, який не використовується Visual Studio. При цьому, оскільки середовище ASP.NET виявляє зміну дати створення збірки, після кожної заміни старої збірки в каталозі bin відбувається перезапуск домену програми, що виливається в тимчасову загальмованість в роботі програми. Visual Studio 2005 використовує нові ключові слова, що підтримуються середовищем виконання ASP.NET 2.0, а середовище виконання, у свою чергу, використовує нову техніку компіляції сторінок. Це дозволяє вирішити проблему заміни складання на новішу. Незважаючи на це, Visual Studio 2005, як і раніше, дозволяє відмовитися від поділу коду і помістити код програмної логіки в самому файлі сторінки, і використовувати теги . Більше того, за умовчанням Visual Studio створює сторінки без поділу коду.
Компіляція сторінок на вимогу
Порівняємо дії, які робить ASP.NET 2.0 та ASP.NET 1.0, коли користувач запитує файл з розширенням .aspx. В ASP.NET 1.x середовище виконання аналізує директиву сторінки, здійснює пошук відповідного класу у складанні програми, потім на основі коду сторінки створюється клас, похідний від класу програмної логіки сторінки. Якщо збірка відсутня, то здійснюється пошук файлу програмної логіки, вказаного в атрибуті SrcДирективи Page. Якщо файл знайдено, відбувається компіляція збірки, якщо ні, то ASP.NET викидає виняток. В ASP.NET 2.0 середовище виконання також аналізує директиви Page, здійснює пошук складання відповідної класу логіки сторінки, після чого створюється клас сторінки. На відміну від ASP.NET 1.x, батьківським класом для класу сторінки є System.Web.UI.Page, оскільки створюваний динамічний клас є власне класом сторінки (використовуються класи, що розділяються, для класу сторінки і класу програмної логіки), а не нащадком класу сторінки логіки. Тому, якщо в ASP.NET 1.x клас Web-форми міг називатися так само як і сама Web-форма.
В ASP.NET 2.0 це неприпустимо, оскільки елемент керування System.Web.UI.Form є елементом класу. Основною перевагою ASP.NET є те, що у разі відсутності складання, необхідного для виконання сторінки, відбувається компіляція лише файлу програмної логіки сторінки, без перекомпіляції всього складання. Оскільки існує динамічна компіляція, необхідно забезпечити можливість створювати код, загальний всім сторінок програми. Для цієї мети в ASP.NET 2.0 існують спеціальні директорії, що є дочірніми директоріями кореневої директорії програми, одна з яких App_Code, служить для зберігання файлів, що містять спільний код для всіх сторінок. При виконанні динамічної компіляції код із директорії App_Code компілюється і стає доступним для всіх сторінок Web-програми. При цьому Visual Studio 2005 підтримує код, що знаходиться в директорії App_Code, тому працює підсвічування синтаксису та IntelliSense. Дослідити генеровані середовищем виконання ASP.NET 2.0 файли, і докладно розібратися в процесі компіляції можна вивчивши вміст директорії:%WINDIT%\Microsoft.NET\Framework\версія\Temporary ASP.NET Files\ім'я_програми , куди ASP.NET 2.0 поміщає динамічно створені збірки. Або, викликавши помилку на сторінці ASP.NET в режимі налагодження вибрати посилання Show Complete Compilation Source.
Зміни у структурі проекту Visual Studio
У версії Visual Studio 2005 немає файлів .csproj або .vbproj, які раніше створювалися для кожного з типів проектів ASP.NET. Замість файлів проекту Visual Studio використовує структуру директорій, таким чином, для того, щоб включити в проект наявний файл, досить просто скопіювати його в директорію проекту . Слід зазначити, що якщо файл або директорія видаляється з дерева файлів проекту у вікні Solution Explorer , файл або директорія фізично видаляються з файлової системи.
Сторінка ASP.NET 2.0
Директива @Page
Вказує на те, який із інтерфейсів IHttpHandler або IHttpAsyncHandler реалізує клас сторінки. Після встановлення цього атрибуту в true, генерований динамічно клас сторінки буде реалізувати від IHttpAsyncHandler, інакше клас буде реалізувати IHttpHandler. Якщо клас сторінки реалізує IHttpAsyncHandler , код сторінки може виконуватися асинхронно до настання нової події в життєвому циклі сторінки PreRender, до часу настання якого відбувається синхронізація та підготовка HTML-коду для відправки браузеру клієнта.
Дозволяє встановити обмеження часу, відведене для виконання асинхронних операцій. За замовчуванням цей параметр дорівнює 45 секунд.
Встановлює набір регіональних параметрів (Culture), який використовується для сторінки.
Дозволяє увімкнути або вимкнути підтримку тем оформлення. За замовчуванням увімкнено.
Вказує шлях до шаблону, який буде використанийдля створення коду цієї сторінки.
Дозволяє встановити ідентифікатор теми оформлення, яка використовуватиметься для зміни встановленої теми оформлення (в атрибуті Theme або у файлі web.confg). Таким чином можна встановити загальну тему оформлення для всього сайту, а за допомогою атрибуту StyleSheetTheme вносити деякі зміни до загального оформлення сторінки та/або деяких елементів керування, що містяться на сторінці.
Вказує назву теми оформлення, яка буде використана для оформлення коду цієї сторінки.
Встановлює набір регіональних параметрів (Culture), що використовується для інтерфейсу користувача сторінки.
Життєвий цикл сторінки
Життєвий цикл сторінки ASP.NET починається з отримання та обробки Web-сервером IIS запиту до цієї сторінки та передачі цього запиту середовищу виконання ASP.NET. У момент отримання запиту, середовище виконання завантажує клас сторінки, що викликається, встановлює властивості класу сторінки, вибудовує дерево елементів, заповнює властивості Request і Response і викликає метод IHttpHandler.ProcessRequest. Після цього середовище виконання перевіряє яким чином була викликана ця сторінка і якщо сторінка викликана шляхом передачі даних з іншої сторінки, про що буде розказано далі, то середовище виконання встановлює властивість PreviousPage. Слід зазначити також, що окрім розглянутих нижче етапів виконання сторінки існують ще й етапи рівня програми, не специфічні для сторінки. Детально про етапи виконання програми написано у цій статті.
Під час проходження етапів життєвого циклу виникають події, підписавшись на які розробник може виконувати свій власний код. Варто згадати атрибут AutoEventWireup, директиви @Page: якщо цей атрибут встановлений у true (значення за замовчуванням), то методи класу сторінки, названі Page_ Назва Події, автоматично стають обробниками відповідних подій життєвого циклу станиці. Для того, щоб простежити життєвий цикл сторінки та послідовність виникнення подій, можна встановити атрибут Trace директиви @Page у true, а атрибут TraceMode у "SortByTime". Тоді в розділі Trace Information можна знайти список подій, що відбулися (колонка Message). Наприклад: