Разработчики Microsoft описали ASP.NET как свой шанс “нажать на кнопку перезапуска” и начать работу с полностью новой, более современной моделью разработки. ASP.NET работает совсем иначе, нежели традиционные технологии написания сценариев, подобные классической системе ASP или PHP.
Дорогие друзья для тех, кто не знаком с ASP.NET (или просто хочет ещё раз просмотреть базовые сведения), я рассказываю о семи основных особенностях .NET-разработки.
Первый факт: ASP.NET интегрируется с .NET Framework
Среда .Net Framework состоит из очень тщательно отобранных функциональных частей, общее количество которых насчитывает более 10 000 типов (типами в .NET называются классы, структуры, интерфейсы и другие ключевые элементы программирования).
Обширная коллекция функциональных возможностей, предлагаемая .NET Framework, упорядочена очень удобным способом. Каждый из тысяч доступных в .NET Framework классов размещается в логическом иерархическом контейнере, который называется пространством имён (namespace).
Разные пространства имён предоставляют разные функциональные возможности, а все вместе они предоставляют функциональные возможности для практически каждой области распределённой разработки, начиная от организации очередей сообщений и заканчивая обеспечением безопасности.
Весь целиком этот обширный набор инструментов называется библиотекой классов (class library).
Второй факт: код ASP.NET компилируется, а не интерпретируется
Одной из главных причин снижения производительности в классических ASP-страницах является
использование интерпретируемого кода сценария. При каждом выполнении ASP-страницы
(не путать с ASP.NET-страницей), находящемуся на Web-сервере механизму
сценариев приходится интерпретировать код сценария и преобразовать его в более низкоуровневый
машинный код строка за строкой, а, как известно, этот процесс выполняется чрезвычайно медленно.
Приложения ASP.NET всегда компилируются: на самом деле выполнить код C# или Visual Basic,
предварительно не скомпилировав его, просто не возможно.
Приложения ASP.NET в действительности проходят два этапа компиляции. На первом этапе написанный
вами код C# компилируется в код на промежуточном языке под названием Microsoft Intermediate Language (MSIL),
или просто IL. Этот первый шаг является фундаментальной причиной взаимозависимости .NET от языков.
Этот первый этап компиляции может произойти автоматически при первом запросе страницы, или же его можно
выполнить заранее (этот процесс известен как предварительная компиляция). Скомпилированный файл с кодом
IL является сборкой.
Второй этап компиляции наступает непосредственно перед фактическим выполнением страницы. На этом этапе код
IL компилируется в низкоуровневый собственный машинный код. Этот этап известен как оперативная компиляция
“точно к нужному моменту” (Just-In-Time – JIT) и он проходит одинаково для всех приложений .NET
(включая, например, приложения Windows). На рис. 1 показан этот двухэтапный процесс компиляции.
Рис. 1. Компиляция в рамках Web-страницы ASP.NET
Компиляция .NET делится на два этапа с целью предоставления разработчикам удобных условий и мобильности. Перед созданием низкоуровневого машинного кода компилятору необходимо знать, в какой операционной системе и на каком базовом оборудовании будет функционировать приложение (например, 32- или 64-разрядная ОС Windows). Благодаря двум этапам компиляции, можно создать скомпилированную сборку с кодом .NET и распределить её на более чем одну платформу.
Приложения ASP.NET не требуют, чтобы компиляция выполнялась при каждом запросе Web-страницы. Вместо этого код IL в них создаётся один раз и генерируется заново только в случае изменения исходного кода, а файлы собственного машинного кода кэшируются в системном каталоге, путь к которому выглядит примерно так:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
В какой именно точке код компилируется в IL, зависит от способа создания и развёртывания приложения. Если приложение создаётся как Web-проект в Visual Studio, код компилируется в IL во время компиляции проекта. Но если оно создаётся как не относящийся ни к какому проекту облегчённый Web-сайт, тогда код каждой страницы компилируется при первом запрашивании этой страницы. Но и в том, и в другом случае, через второй этап компиляции (подразумевающий преобразование из IL-кода в машинный код) код проходит уже при первом выполнении.
Третий факт: ASP.NET поддерживает несколько языков
Выбор для разработки приложения того или иного языка никак не влияет на то, что с ним можно будет делать. А всё потому, что какой бы язык не использовался, код всё равно компилируется в IL.
Понять, что собой представляет IL, легче всего, рассмотрев простой пример. Возьмём следующий код, написанный на языке C#:
using System;
namespace HelloWorld
{
public class TestClass
{
private static void Main(string[] args)
{
Console.WriteLine("Hello World");
}
}
}
Этот код демонстрирует наиболее простое приложение, которое можно создать в .NET – обычную утилиту командной строки, которая отображает в окне консоли сообщение “Hello World”.
Теперь давайте посмотрим на него с другой стороны. Ниже показано, как будет выглядеть IL-код для метода Main():
.method private hidebysig
static void Main(string[] args) cil managed
{
.entrypoint
//Размер кода 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: call void [mscorlib]System.Console
::WriteLine(string)
IL_000b: nop
IL_000c: ret
}
Просмотреть IL-код любого скомпилированного приложения .NET очень легко. Для этого нужно всего лишь запустить программу дизассемблера (IL Disassembler), которая называется ildasm.exe и устанавливается вместе с Visual Studio и .NET SDK (Software Development Kit – набор инструментальных средств разработки ПО). Когда утилита ildasm.exe загрузится, нужно воспользоваться доступной в меню File (Файл) командой Open (Открыть) и выбрать требуемый DLL- или EXE-файл, который был создан с помощью .NET.
Тем, кому нужен более мощный дизассемблер, могут попробовать воспользоваться замечательной (и к тому же бесплатной) программой Reflector, которая доступна для загрузки по следующему адресу: http://www.aisto.com/roeder/dotnet. Благодаря созданным добровольцами подключаемым модулям, она позволяет составлять диаграммы, анализировать и декомпилировать IL-код в любой сборке.
Поскольку клиент никогда не получает скомпилированный файл кода, у клиента нет возможности его дизассемблирования, поэтому проблемы приватности и управления кодом не являются препятствием для разработчиков ASP.NET.
Четвёртый факт: ASP.NET обслуживается CLR
Пожалуй, наиболее важным аспектом механизма ASP.NET является то, что он функционирует внутри исполняющей среды CLR. Вся среда .NET Framework – т.е. все пространства имён, приложения и классы – называется управляемым кодом.
Основные преимущества CLR:
- Автоматическое управление памятью и сборка мусора. Каждый раз, когда приложение создаёт экземпляр объекта ссылочного типа (reference-type object). CLR выделяет для него пространство памяти в управляемой куче. Однако, вам никогда не придётся очищать эту память вручную. Как только ссылка на объект выходит за пределы области видимости (или приложение завершается), объект становится доступным для сборщика мусора. Сборщик мусора периодически запускается внутри CLR, автоматически восстанавливая неиспользованную память для недоступных объектов. Эта модель избавляет от низкоуровневых деталей манипулирования памятью C++ и от запутанности подсчёта ссылок COM.
- Безопасность типов. При компиляции приложения .NET добавляет в сборку сведения о доступных классах, их членах, типах данных и т.д.Это позволяет другим приложениям использовать их, не требуя дополнительных вспомогательных файлов, а компилятору – удостоверяться в правильности запроса прямо во время выполнения. Такой дополнительный уровень безопасности полностью исключает вероятность возникновения всех видов низкоуровневых ошибок.
- Расширяемые метаданные. Информация о классах и членах является только одним из типов метаданных, которые .NET может хранить в скомпилированной сборке. Метаданные описывают код и позволяют предоставлять дополнительную информацию исполняющей среде и другим службам. Например, эти метаданные могут указывать отладчику, как следует выполнять трассировку кода, или же сообщать Visual Studio о том, как во время проектирования должен отображаться какой-нибудь специальный элемент управления. Они также могут использоваться и для активизации ещё каких-нибудь служб во время выполнения, например, для активизации транзакций или пула объектов.
- Структурированная обработка ошибок. Языки .NET поддерживают структурированную обработку исключений, что позволяет организовывать код обработки ошибок логичным и последовательным образом, т.е. создавать для разных типов ошибок отдельные блоки, а также размещать обработчики исключений на глубине в целых несколько уровней.
- Многопоточность. CLR предоставляет пул потоков, которые могут использоваться различными классами. Например, можно асинхронно вызывать методы, читать файлы, либо взаимодействовать с Web-службами без необходимости явного создания новых потоков.
На рис. 2 показана высокоуровневая структура CLR и .NET Framework.
Рис. 2. CLR и .NET Framework
Пятый факт: ASP.NET является объектно-ориентированной технологией
Она не только предоставляет полный доступ ко всем объектам в .NET Framework, но и позволяет использовать все концепции объектно-ориентированного программирования (ООП). Например, она позволяет создавать повторно используемые классы, стандартизовать код с помощью интерфейсов, расширять существующие классы посредством наследования и объединять полезные функциональные возможности в пригодный для распространения скомпилированный компонент.
Одним из наилучших примеров поддержки объектно-ориентированного поведения в ASP.NET являются серверные элементы управления. Эти элементы управления представляют собой инкапсуляцию в миниатюре. Разработчики могут манипулировать их объектами программно, используя код для настройки их внешнего вида, предоставления подлежащих отображению данных и даже реагирования на события. Вся низкоуровневая HTML-разметка, которую визуализируют эти элементы управления, скрывается “за кулисами”. Вместо того чтобы вынуждать разработчика писать низкоуровневый код HTML-разметки вручную, объекты этих элементов управления сами преобразовываются в соответствующие HTML-элементы по завершении визуализации страницы. Таким образом, ASP.NET позволяет с помощью серверных элементов абстрагироваться от низкоуровневых деталей HTML- и HTTP-программирования.
Шестой факт: ASP.NET поддерживает множество устройств и браузеров
Несмотря на то, что вы можете извлекать информацию о браузере клиента и его свойствах внутри страницы ASP.NET, ASP.NET фактически побуждает разработчиков игнорировать эти соображения и использовать обширный набор элементов управления Web-сервера. Эти серверные элементы управления генерируют HTML, адаптируясь к возможностям клиента. Одним из примеров являются элементы управления верификацией ASP.NET, использующие JavaScript и DHTML (динамический HTML) для совершенствования своего поведения, если оно поддерживается клиентом. Это позволяет элементам управления верификацией отображать сообщения о динамических ошибках без необходимости отправки пользователем страницы серверу для продолжения обработки. Эти свойства необязательны, но они демонстрируют то, как интеллектуальные элементы управления могут составлять большую часть современных браузеров, не требуя других клиентов. Но самое лучшее заключается в том, что вам не нужны дополнительные работы по кодированию для поддержания обоих типов клиента.
Седьмой факт: ASP.NET легко развёртывается и конфигурируется
Процедура развёртывания приложения ASP.NET в общем подразумевает всего лишь копирование всех файлов в виртуальный каталог на производственном сервере (с помощью программы FTP или даже утилиты командной строки XCOPY). Если на машине-хосте установлен компонент .NET Framework, выполнять какие-либо трудоёмкие шаги по регистрации не потребуется.
Процедура распространения компонентов, используемых приложением, выглядит столь же просто и предполагает всего лишь копирование сборок компонентов вместе с файлами Web-сайта на этапе развёртывания Web-приложения. Поскольку вся информация о компоненте хранится прямо в метаданных файла сборки, запускать программу регистрации или вносить изменения с системный реестр Windows не требуется. При условии размещения компонентов в “правильном месте” (каковым является подкаталог bin внутри основного каталога Web-приложения), механизм ASP.NET автоматически обнаруживает их и делает доступными для кода Web-страницы.
Конфигурирование является ещё одной задачей, связанной с развёртыванием приложения, в особенности при необходимости передачи информации о безопасности, такой как учётная запись и привилегии пользователя. ASP.NET упрощает процесс развертывания, сводя к минимуму зависимость от настроек IIS (Internet Information Services — информационные службы Internet). Вместо этого большинство установок ASP.NET хранится в специальном файле web.config. Файл web.config помещается в тот же каталог, что и Web-страницы. Он содержит иерархически сгруппированные настройки приложения, хранимые в удобочитаемом формате XML, который можно редактировать с использованием простого текстового редактора, подобного Notepad. При изменении настройки приложения ASP.NET замечает это изменение и перезапускает приложение в новом домене приложения (поддерживая существующий домен приложения вплоть до завершения обработки каких-то невыполненных запросов). Файл web.config никогда не блокируется, поэтому его можно обновлять в любое время.