Microsoft ASP.NET vNext: эволюция или революция?

В начале мая месяца впервые была представлена Visual Studio 14 CTP 1, а вместе с ней и предварительная версия технологии ASP.NET для разработки веб-приложений нового поколения. Ну и примерно месяц назад вышла третья альфа версия новой технологии вместе с Visual Studio 14 CTP 3. Какие преимущества и что нового даёт нам обновлённая технология? Если сказть, что в ней очень много нового – значит не сказать ничего. Попробую пройтись с самого начала и описать всё. А началось всё со спецификации OWIN, которая описана в данном цикле статей и нам уже должна быть знакома. Новая версия ASP.NET целиком и полностью базируется на данной спецификации. С выходом Visual Studio 2013 была представлена новая концепция "Единый ASP.NET" («One ASP.NET»), а также впервые была применена спецификация OWIN на практике. Ну и конечно, появился такой "костыль", как заставить IIS/ASP.NET использовать эту спецификацию для построения приложений. Правда испытать реальные возможности, которые дают приложения построенные по спецификации OWIN, можно только без использования IIS/ASP.NET. Как видно из последней статьи, чтобы всё это добро использовать нужно хорошенько постараться, да и использовать ASP.NET MVC не было возможности из-за тесной интеграции с .NET Framework (библиотека System.Web.dll). Т.е. она не вписывалась в спецификации OWIN. А что теперь? Допилили, доделали да и ещё добавили много нового, как говорится – "всё из коробки", не надо ничего напридумывать. Можно просто взять и использовать. Встречаем ASP.NET vNext под кодовым названием"Project K" ("К" в этом имени расшифровывается как "Katana", по словам разработчиков Microsoft). По сути vNext является продолжением проекта "Katana" (новая CLR, новый компилятор, новые абстракции, новая структура проекта). Но обо всём новом по порядку. Отмечу, что исходный код ASP.NET vNext открыт полность и находится на хостинге GitHub. Начнём мы рассматривать все новшества с использованием уже готового проекта ASP.NET vNext. Для начала посмотрим на два разных варианта данного приложения: используются Visual Studio 14 CTP 3 с ASP.NET vNext  и Visual Studio 2013 с ASP.NET 4.5.1 .



Как видно из вышеприведённого рисунка есть два заметных изменения: отсутствуют файлы web.config и AssemblyInfo.cs. Вместо них используется конфигурация c использованием JSON, в часности файл конфигурации project.json. Он содержит информацию о подключённых сборках, (т.е. отпала необходимость в файле packages.config) параметры конфигурации, параметры компиляции и многое другое. Более подробно о его сруктуре можно почитать тут. Как обычно, при редактировании подобного файла в Visual Studio есть поддержка IntelliSense.



Ещё одно приятное нововведение в Visual Studio 14, возможность посмотреть на иерархию зависимостей сборок на вкладке References. При открытии вкладки на первом уровне дерева показываются те сборки от котрых зависит непосредственно само приложение. Далее продолжая открывать их, можно увидеть все конечные зависимости текущей сборки. Например сборка Microsoft.AspNet.Mvc.Common зависит в конечном счёте от сборок: System.Linq, System.Reflection, System.Reflection.Extensions, System.Runtime, а последние в свою очередь, как видно из нижеприведённого рисунка, не зависят ни от чего.



Сильно "похудела" и вкладка "Свойства проекта (Properties)". Как видно из нижеприведённого рисунка, доступны всего две ветки опций: Common Properties и Configuration Properties. Первая вкладка только содержит вкладку Debugging, где можно всего-навсего задать порт сервера раработки (DevelopmentServerPort). Вторая тоже пока содержит только одну ветку General со значениями: Active Target Framework (.NET Framework 4.5.1 или .NET Core Framework 4.5), Root Namespace (пространство имен приложения), Output Type (тип приложения при построении: Web Application, Console Application или Class Library) и K Runtime Version (версия среды выполнения).



Если значения свойств Root Namespace и Output Type интуитивно понятны, то над значениями оставшихся двух стоит остановиться и рассмотреть их более детально.



Чтобы понять значения свойств Active Target Framework и K Runtime Version нужны базовые знания новых принципов и архитектуры. Попытаюсь описать в общих чертах. Начну с описания новой среды выполнения для "Project K". Называется она – "KRuntime". Это код, необходимый для начальной загрузки и запуска приложения ASP.NET vNext. Он включает в себя такие вещи, как систему компиляции, SDK инструменты и хосты CLR. Ссылка на проект исходного кода находится здесь и он является частью "Project K" (ASP.NET vNext). А более или менее подробное описание и схема структуры K Runtime  с рисунком приведена здесь. Для удобства привожу его здесь также.



Если приглядеться, то это не что иное, как намного более развитая и совершенная версия структуры проекта Katana (в статье: визуальная схема архитектуры проекта Katana), с использованием новых средств и технологий и нацелена также для использования в платформах отличных от Windows. То есть, как я сказал выше, vNext – преемник "Katana". Рекомендую ознакомиться с последней статьей, чтобы дальше всё было понятно, так как в дальнейшем я буду сслылаться на неё. Как видно, рисунок разделён на две большие части: K Host и K Runtime. Из него видно, что первым идет нулевой слой (Layer 0 : Native Process) относящийся к K Host. Это конечная точка или контейнер в котором будет выполняться всё приложение. Для операционной системы семейства Windows это процессы самой ОС. В случае использования IIS/ASP.NET по спецификации OWIN (ASP.NET Project "Helios") таковым является рабочий процесс пула W3WP.EXE. Можно хостить приложение в пользовательском процессе (например в консольном, как в случае с проектом Katana). На данный момент, при использовании Visual Studio 14 CTP 3, есть только одна возможность, использовать IIS Express для хостинга. Другие варианты, скорее всего, появятся в будущем. Слой под номером один (Layer 1 : CLR Native Host) уже относится непосредственно к K Runtime. Этот слой является специфическим для версии CLR, который используется, и имеет две основные обязанности. Первое – загрузка CLR, процесс загрузки зависит от версии CLR, для Core CLR например процесс предполагает загрузку coreclr.dll, настройку и запуск среды выполнения, и создание домена приложения (AppDomain), где весь управляемый код будет работать. Второе – вызов управляемой входной точки (Managed Entry Point) представленная вторым слоем (Layer 2). Если теперь приглядеться к рисункам ниже, станет понятно как используется свойство Active Target Framework.  При запуске приложения  с использованием значения .NET Framework 4.5.1 используется уже имеющаяся и хорошо знакомая нам версия CLR Version 4.0.30319.



А вот установив Active Target Framework как .NET Core Framework 4.5 имеем уже совсем другой результат, как показывает нижний рисунок.



Слой под номером два, является первым полностью написанным на управляемом коде. Основная его задача – разрешение зависимостей для сборок при загрузке последних для CLR, и вызова метода входной точки предоставленного приложения для третьего слоя. Третий слой (Layer 3: Application host / Application) является последним в K Runtime.  Это связующее звено между пользовательским кодом и KLR или это само приложение. Именно здесь может происходить обход файла конфигурации для разрешения зависисимых сборок. Последний слой (Layer 4 : Application) представляет пользовательское приложение, код написанный разработчиком. Теперь уже стало понятно, что подразумевается под K Runtime Version в свойствах проекта. Получается, что их может быть несколько на одной машине.



Думаю, с KRuntime примерно всё понятно, более точное и детальное описание будет дано в будущих статьях. Тереь, что касается технологии. MVC, Web API и Web Pages объединены в один под общим названием MVC 6. Как и в случае проекта Katana, хостить приложения vNext, можно вне IIS, это уже понятно из вышеизложенного. Но тут ещё добвилась новая возможность – кроссплатформенность, можно использовать vNext вне Windows.  Код vNext полность новый, продуман и оптимизирован, от этого приложение занимает меньше ресурсов машины. При использовании .NET Core Framework, размер дистрибутива фреймворка меняется сильно, следовательно приложения тоже, порядка 11 МБ вместо 200МБ. Это позволяет использовать меньше ресурсов при развёртывании в облаке. Также есть возможнось запуска и развёртывания разных независимых версий приложений vNext, на одной машине. Это очень полезная возможность в случае использования облачных технологий. ASP.NET vNext использует компилятор Roslyn, что позволяет использовать динамическую компиляциию кода. То есть в случае редактирования, не будет необходимости компилировать проект заново вручную. Достаточно сделать изменения и увидеть результат выполнения кода приложения. Что касается нового API кода, то тут всё интуитивно понятно и почти по старому, хотя код новый, названия классов и объектов почти одинаковые. Используется та же спецификация OWIN, только с новым модулем Owin (MVC 6). Пример приложения можно посмотреть здесь, позже, в одельной статье я опишу его подробно. Больше сведений о ASP.NET vNext можно получить с официального сайта ASP.NET.

И так, подводя итоги и отвечая на главный вопрос: эволюция или революция? Однозначно второй вариант – революция. Почему так? Думаю, ответ уже ясен из статьи, изменеий очень много и они кардинальные. Но если коротко, то: вся инфраструктура (ну почти вся) построена при помощи управляемого кода, неуправляемого кода попросту нет (нет нативных и управляемых HTTP-модулей и т.д. и т.п.), весь код тут новый (старого кода попросту нет), вся технология/фреймворк чётко разделён на отдельные компонеты (этому содействует спецификация OWIN). Всё это способствует открытию новых возможностей для разработки современных веб-приложений. Хотя, если задуматься, то и последние версии технологии ASP.NET тоже очень хорошие. Но, в любом случае, прогресс – дело хорошее.