Нашли ошибку или опечатку? Выделите текст и нажмите

Поменять цветовую

гамму сайта?

Поменять
Обновления сайта
и новые разделы

Рекомендовать в Google +1

Особенности ASP.NET

189
1

С выходом первой версии .NET Framework около десяти лет назад в сфере проектирования программного обеспечения появилось совершенно новое направление. Вдохновленные наилучшими возможностями Java, COM и веб-технологий и обученные на ошибках и ограничениях прежних технологий, разработчики в Microsoft решили полностью обновить свою платформу для разработки.

В результате этого появился ряд удивительно совершенных технологий для выполнения всего, начиная от построения приложений Windows и заканчивая выполнением запросов в базах данных, и специально ориентированный на разработку веб-сайтов инструмент под названием ASP.NET.

Сегодня ASP.NET пользуется небывалой популярностью, но особо революционной технологией уже больше не является. И хотя базовые функциональные возможности, лежащие в основе ASP.NET, на удивление, выглядят точно так же, как и десять лет назад, разработчики из Microsoft добавили к ним еще кое-какие дополнительные средства и абстракции кодирования более высокого уровня.

Также появилось и еще как минимум одно новое направление, составляющее конкуренцию традиционному программированию с использованием ASP.NET, которое получило название ASP.NET MVC.

Когда платформа ASP.NET была выпущена впервые, от предыдущих продуктов Microsoft и конкурирующих платформ ее отличали семь ключевых фактов. Тем, кто перешел на ASP.NET с какой-то другой платформы для разработки веб-приложений, или еще никогда не программировал в .NET приложений для веб-сети, материал следующих разделов позволит быстро получить общее представление об ASP.NET.

ASP.NET интегрируется с .NET Framework

Платформа .NET Framework делится на практически неповторимый ряд функциональных частей с десятками тысяч типов (в .NET так называются классы, структуры, интерфейсы и другие ключевые элементы программирования). Прежде чем пытаться программировать любое приложение .NET, необходимо сначала получить хотя бы общее представление об этих частях и о том, почему они организованы именно таким, а не каким-то другим образом.

То, как организована предлагаемая в .NET Framework обширная коллекция функциональности, программистам традиционных Windows-приложений, несомненно, покажется замечательным улучшением. Каждый из тысяч доступных в .NET Framework классов размещен в логическом иерархическом контейнере, который называется пространством имен (namespace).

В разных пространствах имен предоставляется разная функциональность, но все вместе они предлагают функциональные возможности для практически каждого аспекта области распределенной разработки, начиная с организации очередей сообщений и заканчивая обеспечением безопасности. Весь целиком этот обширный набор инструментов называется библиотекой классов (class library).

Интересно то, что способ, которым классы .NET Framework можно использовать в ASP.NET, ничем не отличается от того, которым они применяются в приложениях .NET любого другого типа (в том числе автономных Windows-приложениях, Windows-службах, утилитах командной строки и т.д.).

Хотя в .NET предлагаются ориентированные специально на Windows- и на веб-приложения классы для построения пользовательских интерфейсов, большинство возможностей .NET Framework (начиная с получения доступа к базам данных и закачивания поддержкой многопоточной обработки) допускается использовать в приложениях любого типа. Другими словами, в .NET разработчикам веб-приложений предлагаются те же самые инструменты, что и разработчикам многофункциональных клиентских приложений.

Код ASP.NET компилируется, а не интерпретируется

Подобно всем приложениям .NET, приложения ASP.NET всегда компилируются. На самом деле выполнение кода на C# или Visual Basic без предварительной компиляции просто невозможно.

Приложения ASP.NET в действительности проходят через два этапа компиляции.

На первом этапе написанный код на C# компилируется в код на промежуточном языке, который называется MSIL (Microsoft Intermediate Language — промежуточный язык Microsoft), или просто IL. Этот первый этап как раз и является одной из главных причин, по которым в .NET могут использоваться самые разные языки.

Дело в том, что все языки .NET (в том числе C#, Visual Basic и многие другие), по сути, компилируются в практически идентичный код IL. Этот первый этап компиляции может происходить как автоматически при первом запросе страницы, так и выполняться заранее (это называется предварительной компиляцией). Скомпилированный файл с кодом на IL представляет собой сборку.

Второй этап компиляции происходит непосредственно перед фактическим выполнением страницы. На этом этапе код IL компилируется в код на низкоуровневом машинном языке. Называется этот этап оперативной (Just-In-Time — JIT) компиляцией и выглядит одинаково для всех приложений .NET (включая, например, Windows-приложения).

На следующем рисунке показан этот состоящий из двух этапов процесс компиляции:

Процесс компиляции, выполняемый в рамках веб-страницы ASP.NET

Процесс компиляции в .NET разделен на два этапа для предоставления разработчикам как можно большего удобства и мобильности. Перед тем, как создавать код на низкоуровневом машинном языке, компилятор должен знать, в какой операционной системе и на каком базовом оборудовании будет выполняться приложение (например, будет это 32- или 64-разрядная ОС Windows). Благодаря выполнению таких двух этапов компиляции, можно создавать скомпилированную сборку с кодом .NET и по-прежнему распространять ее среди более, чем одной, платформы.

Разумеется, этап оперативной компиляции, пожалуй, не был бы столь полезным, если бы его нужно было выполнять при каждом запросе той или иной страницы веб-сайта. К счастью, приложения ASP.NET не нуждаются в выполнении компиляции при каждом запрашивании веб-страницы. Вместо этого код на IL в них создается один раз и генерируется заново только в случае изменения исходного кода, а файлы, содержащие машинный код, кэшируются в системном каталоге, путь к которому выглядит примерно так:

C:\Windows\Microsoft.NET\Framework\[Номер версии]\Temporary ASP.NET Files.

Конкретный момент, когда код компилируется в IL, зависит от того, каким образом создается и развертывается веб-приложение. В случае создания веб-приложения в виде веб-проекта в Visual Studio код компилируется в IL при компиляции проекта. В случае его создания в виде облегченного веб-сайта без проекта, код для каждой из его страниц компилируется при первом запросе соответствующей страницы. Но и в том, и в другом случае через второй этап компиляции (из IL в машинный код) код проходит лишь при первом его запуске.

В ASP.NET также включены инструменты для выполнения предварительной компиляции, с помощью которых можно делать так, чтобы приложение компилировалось сразу же в машинный код прямо после его развертывания на производственном веб-сервере. Это позволяет избежать накладных расходов, связанных с выполнением первого этапа компиляции при развертывании готового приложения (и исключить возможность подделки или изменения кода другими людьми).

В ASP.NET поддерживается множество языков программирования

Хотя при разработке приложения предпочтение, скорее всего, будет отдано какому-то одному языку, выбор языка никак не влияет на то, какие задачи с помощью приложения можно будет решать. Причина в том, что какой бы язык ни использовался, код всегда будет компилироваться в IL.

Язык IL является своего рода "трамплином" для любого управляемого приложения. Под управляемым, (managed) приложением понимается любое приложение, которое пишется для .NET и выполняется внутри управляемой среды CLR.

В некотором смысле IL даже можно назвать языком .NET, потому что он является единственным языком, который распознает исполняющая среда CLR.

Чтобы лучше понять, что собой представляет IL, не помешает рассмотреть простой пример. Поэтому давайте возьмем следующий код на языке C#:

using System; 
namespace HelloWorld 
{ 
   public class TestClass 
   { 
        private static void Main(string [ ] args) 
        { 
             Console.WriteLine ("Hello World"); 
        } 
   } 
} 
   

Этот код показывает, как может выглядеть самое простое из всех возможных в .NET приложений, а именно — простая утилита командной строки, которая отображает в окне консоли предсказуемое сообщение.

Теперь посмотрим на него с другой стороны. Ниже приведен код IL для его метода Main():

.method private hidebysig static void Main(string[] args) cil managed 
{ 
   .entrypoint 
   // Размер кода 13 (Oxd) 
   .maxstack 8 
   IL_0000: nop 
   IL_0001: ldstr "HelloWorld" 
   IL_0006: call void [mscorlib]System.Console::WriteLine(string) 
   IL_000b: nop 
   IL_000c: ret , 
} // конец метода TestClass::Main
   

Просмотреть IL-код для любого скомпилированного приложения .NET довольно легко. Подробнее читайте об этом в статье - Промежуточный язык CIL.

За счет терпения и небольших логических рассуждений можно разобраться в коде IL и вычислить, что в нем происходит. Тот факт, что IL настолько просто дизассемблируется, чреват проблемами с конфиденциальностью и управлением кодом, но разработчики приложений ASP.NET беспокоиться об этом не должны, потому что весь код ASP.NET сохраняется и выполняется на сервере. Поскольку клиент никогда не получает скомпилированного файла кода, никакой возможности декомпилировать его не будет.

Если же подобные проблемы все-таки беспокоят, рассмотрите вариант применения маскировщика (обфускатора) для запутывания кода и превращения его в более трудный для понимания. (Маскировщик, например, может переименовать все переменные и назначить им имена вроде f__а__234). В состав Visual Studio входит ограниченная версия популярного маскировщика Dotfuscator.

Важно отметить, что IL был недавно признан стандартом Ecma и ISO. Это может послужить толчком к скорому признанию таковым и других общеязыковых платформ, предназначенных для использования на других платформах. Наилучшим примером является проект Mono.

ASP.NET обслуживается средой CLR

Пожалуй, наиболее важным аспектом механизма ASP.NET является то, что функционирует он внутри исполняющей среды CLR. Все части .NET Framework — т.е. все пространства имен, приложения и классы — называются управляемым кодом. Ниже перечислены некоторые из предоставляемых ею преимуществ:

Автоматическое управление памятью и сборкой мусора

При каждом создании в приложении экземпляра объекта ссылочного типа CLR выделяет для него в памяти соответствующее пространство в управляемой куче. Вручную очищать это пространство в памяти никогда не потребуется. При выходе ссылки на объект за пределы области видимости (или завершении работы приложения) объект сразу же становится доступным для сборщика мусора.

Сборщик мусора периодически запускается внутри CLR и автоматически восстанавливает неиспользуемую память, которую занимают более недоступные объекты. Подобная модель избавляет от необходимости иметь дело с низкоуровневыми деталями манипулирования памятью в C++ и запутанного подсчета ссылок в СОМ.

Безопасность типов

При компиляции приложения .NET добавляет в сборку сведения о доступных классах, их членах, типах данных и т.д. Это позволяет использовать их в других приложениях без добавления дополнительных файлов поддержки, а компилятору — удостоверяться в правильности вызова во время выполнения. Такой дополнительный уровень безопасности полностью исключает вероятность возникновения целого ряда низкоуровневых ошибок.

Расширяемые метаданные

Информация о классах и членах является только одним из типов метаданных, которые .NET может сохранять в скомпилированной сборке. Метаданные описывают код и позволяют предоставлять дополнительную информацию исполняющей среде и другим службам. Например, эти метаданные могут указывать отладчику, как следует выполнять трассировку кода, или же сообщать Visual Studio о том, как во время проектирования должен отображаться какой-то специальный элемент управления. Они также могут использоваться для активизации других служб во время выполнения, например, запуска транзакций или пула объектов.

Структурированная обработка ошибок

В языках .NET поддерживается возможность структурированной обработки исключений, которая позволяет организовывать код обработки ошибок логичным и последовательным образом. Можно создавать отдельные блоки для разных типов ошибок, а также размещать обработчики исключений на глубине в несколько уровней.

Многопоточностъ

Среда CLR предоставляет пул потоков, которые различные классы могут использовать. Например, можно вызывать методы, считывать файлы и взаимодействовать с веб-службами асинхронным образом, не создавая явно никаких новых потоков.

ASP.NET является объектно-ориентированной технологией

Технология ASP предоставляет довольно слабую объектную модель. Она поддерживает весьма небольшой набор объектов, которые являются просто тонким уровнем, скрывающим детали HTTP и HTML.

Напротив, ASP.NET является самой настоящей объектно-ориентированной технологией. Она не только предоставляет коду полный доступ ко всем объектам .NET Framework, но и позволяет использовать все концепции объектно-ориентированного программирования (ООП). Например, она позволяет создавать пригодные для повторного использования классы, стандартизировать код с помощью интерфейсов, расширять существующие классы за счет наследования и объединять полезные функциональные возможности в распространяемый скомпилированный компонент.

Одним из наилучших примеров поддержки объектно-ориентированного поведения в ASP.NET являются серверные элементы управления. Эти элементы управления представляют собой инкапсуляцию в миниатюре. Разработчики могут манипулировать объектами элементов управления программно с использованием кода для настройки их внешнего вида, предоставления отображаемых данных и даже реагирования на события.

Вся низкоуровневая HTML-разметка, которую визуализируют эти элементы управления, скрывается из вида. Вместо того чтобы вынуждать разработчика писать низкоуровневый код HTML-разметки вручную, объекты этих элементов управления сами преобразуются в соответствующие HTML-элементы непосредственно перед отправкой веб-сервером страницы клиенту.

Таким образом, серверные элементы управления в ASP.NET позволяют абстрагироваться от низкоуровневых деталей программирования HTML и HTTP.

Ниже приведен небольшой пример со стандартным текстовым полем HTML, которое можно определить в веб-странице ASP.NET:

<input type="text" id="myText" runat="server" /> 
   

После добавления атрибута runat="server" этот статический фрагмент HTML превращается в полностью функциональный серверный элемент управления, которым можно манипулировать в коде. После этого можно работать с генерируемыми им событиями, устанавливать атрибуты и привязывать его к источнику данных.

Например, установить текст для этого поля при первой загрузке страницы можно с помощью следующего кода C#:

void Page_Load(object sender, EventArgs e) 
{ 
      myText.Value = "Hello World!"; 
} 
   

В этом коде устанавливается свойство Value объекта HtmlInputText. В конечном итоге указанная строка появится в текстовом поле на визуализируемой и отправляемой клиенту HTML-странице.

HTML- и веб-элементы управления

На момент создания ASP.NET существовало два типа мышления. Одних разработчиков ASP.NET больше интересовали серверные элементы управления, которые бы в точности соответствовали существующему набору элементов управления HTML. Такой подход позволяет создавать интерфейсы для веб-страниц ASP.NET в редакторах HTML и предоставляет быстрый путь для миграции существующих страниц ASP.

Однако другие разработчики ASP.NET видели будущее в другом — в многофункциональных серверных элементах управления, которые бы не просто имитировали отдельные дескрипторы HTML. Эти элементы управления могли бы визуализировать свой интерфейс из десятков отдельных элементов HTML и при этом все равно предоставлять программистам простой объектный интерфейс для работы и позволять им использовать программируемые меню, календари, списки данных, средства проверки данных и т.д.

После некоторых размышлений в Microsoft решили обеспечить обе этих модели. Пример серверных элементов управления HTML, отображаемых непосредственно на базовый набор HTML-дескрипторов, уже был показан ранее. Кроме них в ASP NET еще предлагаются и так называемые веб-элементы управления, которые предоставляют более высокий уровень абстракции и больше функциональных возможностей.

В большинстве случаев серверные элементы управления HTML применяются для обеспечения обратной совместимости и выполнения быстрой миграции, а веб-элементы управления — для создания новых проектов.

Дескрипторы веб-элементов управления в ASP.NET всегда начинаются с префикса asp:, за которым следует имя класса. Ниже показан пример создания текстового поля и флажка:

<asp:TextBox id="myASPText" Text="Hello ASP.NET TextBox" runat="server" /> 
<asp:CheckBox id="myASPCheck" Text="My CheckBox" runat="server" />
   

С этими элементами управления тоже можно взаимодействовать в коде следующим образом:

myASPText.Text = "New text"; 
myASPCheck.Text = "Check me!"; 
   

Обратите внимание, что свойство Value, которое использовалось в случае элемента управления HTML, здесь заменено свойством Text. Свойство HtmlInputText.Value было переименовано в соответствии со значением базового атрибута в HTML-дескрипторе <input>. В веб-элементах управления акцент на преемственности с синтаксисом HTML не делается, поэтому для свойства вместо этого применяется такое более описательное имя, как Text.

В состав семейства веб-элементов управления в ASP.NET входят как сложные визуализируемые элементы управления (вроде Calendar и TreeView), так и более упрощенные элементы управления (наподобие TextBox, Label и Button), которые довольно близко отображаются на существующие дескрипторы HTML. В последнем случае серверные HTML-элементы управления и их веб-варианты в ASP.NET предоставляют похожую функциональность, но веб-элементы управления делают это через более стандартизированный и упрощенный интерфейс.

В результате веб-элементы управления проще в освоении, а также более естественно подходят разработчикам Windows-приложений, которые переходят на разработку веб-приложений, потому что многие из имен их свойств похожи на имена соответствующих элементов управления Windows.

ASP.NET поддерживает все браузеры

Одним из самых больших испытаний для разработчиков веб-приложений является необходимость в обеспечении поддержки множества различных браузеров. В разных браузерах, версиях и конфигурациях технологии HTML, CSS и JavaScript поддерживаются по-разному. Разработчики веб-приложений должны выбирать, визуализировать содержимое в соответствии с наименьшими общими характеристиками или добавлять фрагменты для принятия во внимание специфических особенностей популярных браузеров.

В ASP.NET эта проблема решена удивительно интеллектуальным способом. Хотя внутри страницы ASP.NET можно извлечь информацию о браузере клиента и его возможностях, в действительности в ASP.NET рекомендуется игнорировать такой подход и пользоваться развитым комплектом серверных веб-элементов управления.

Эти серверные элементы управления генерируют разметку адаптивным образом, принимая во внимание все возможности клиента. Примером могут служить предлагаемые в ASP.NET элементы управления верификацией, которые используют JavaScript и DHTML (динамический HTML) для улучшения своего поведения в случае, если они поддерживается клиентом.

Другим примером является набор оснащенных Аjах элементов управления, которые применяют сложные процедуры JavaScript для проверки версий браузеров и используют тщательно протестированные обходные пути для обеспечения согласованного поведения. Эта функциональность является необязательной, но демонстрирует то, как интеллектуальные элементы управления могут извлекать максимум выгоды из современных браузеров без отгораживания от других клиентов. Лучше всего то, что никакого дополнительного кода для обеспечения поддержки обоих типов клиента писать не требуется.

ASP.NET позволяет легко выполнять развертывание и конфигурирование

Одним из самых трудных процессов, с которым разработчикам приходится сталкиваться, является развертывание готового приложения на производственном сервере. Понадобится не только переместить файлы веб-страниц, базы данных и компоненты, но и зарегистрировать эти компоненты, а также воссоздать ряд конфигурационных настроек. ASP.NET значительно упрощает этот процесс.

Каждая установленная копия .NET Framework обеспечивает те же самые ключевые классы. Благодаря этому процедура развертывания приложения ASP.NET выполняется относительно просто. Часто достаточно всего лишь скопировать все файлы в виртуальный каталог на производственном сервере (с помощью программы FTP или даже утилиты командной строки вроде XCOPY).

Если на целевой машине имеется копия .NET Framework, то предпринимать какие-то трудоемкие действия по регистрации не понадобится.

Распространение компонентов, которые используются в приложении, столь же просто. Для этого при развертывании веб-приложения нужно скопировать сборки компонентов вместе с файлами веб-сайта. Благодаря тому, что вся информация о компонентах сохраняется прямо в метаданных внутри файлов сборок, запускать программу регистрации и вносить изменения в системный реестр Windows не требуется.

При условии размещения всех этих компонентов в правильном месте (подкаталог Bin в каталоге веб-приложения), механизм ASP NET автоматически обнаруживает их и делает доступными для кода веб-страницы. С традиционными компонентами СОМ подобное было невозможно.

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

В ASP NET решение этой задачи тоже упрощено за счет минимизации зависимости от настроек IIS (Internet Information Services — информационные службы Интернета).

Вместо этого большинство конфигурационных настроек ASP.NET хранится в специальном файле web.config. Этот файл web.config размещен в том же каталоге, что и веб-страницы, и содержит иерархически сгруппированные параметры приложения в удобном для прочтения формате XML. Этот файл можно изменять в простом текстовом редакторе, подобном Notepad (Блокнот).

При изменении какого-то параметра приложения ASP NET замечает это изменение и гладко перезапускает приложение в новом домене приложения (поддерживая существующий домен приложения в активном состоянии вплоть до завершения обработки всех оставшихся запросов). Файл web.config никогда не блокируется, и потому может обновляться в любое время.

Alexandr Erohin ✯ alexerohinzzz@gmail.com © 2011 - 2017