Partager via

Платформа ASP.NET Core 1.0. Часть 2: ASP.NET сегодня или что же выбрать?

  • Article

Многие, в том числе и я, достаточно долго ждали выхода финальной версии .NET Core и ASP.NET Core и конечно дождались. Всего пару месяцев назад была выпущена RTM версия технологии для разработки веб приложений, получившая название ASP.NET Core 1.0. Напомню, что  ещё в начале текущего года именовалась она как ASP.NET 5. Продалжая данный цикл статей,  в детали темы. Всё самое новое, то, что сегодня может предоставить новейшая версии платформы Microsoft .NET, в общих чертах, было уже описано. Что ещё мы получим используя последнюю версию платформы .NET, а также более развёрнутое описание технологий веб-разработки, которые предлагает нам Microsoft сегодня будет дано далее и в последующих статьях. Достаточно открыть Visual Studio 2015 Update 3 с последней на данный момент версией Microsoft ASP.NET and Web Tools (VS2015Tools.Preview2.0.1), чтобы увидеть всё, что доступно нам уже сегодня.

Из вышеприведённого изображения видно, что существует целых две категории шаблонов для ASP.NET приложений, для новейшей версии ASP.NET Core 1.0 и обновлённой – ASP.NET 4.5.1, которая официально получила номер ASP.NET 4.6. Насчёт последней цифры в версии было много споров, выбор был между номерами 4.5.3 и 4.6, в конце, на основе мнений большинства, остановились на последней. Разработчик, имеющий опыт работы с предыдущими версиями платформы наверняка в первую очередь продумает, что данный шаблон сделан для совместимости и для сопровождения предыдущих версий технологии. По крайней мере так было всегда, вспомним Visual Studio 2010/2012/2013. Так ли это? Отчасти, да. Но, с большими оговорками: помните рисунок из предыдущей статьи? Если оставить только содержимое для веба, то получи примерно следующее:

Получается, что существует целых две актуальных технологии для разработки веб-приложений сегодня: ASP.NET 4.6 и ASP.NET Core 1.0, которые нам предлагает Microsoft. Детальное описание новейшей версии – ASP.NET Core будет дано в последующих статьях, в данной сравним обе  друг с другом. Для начала посмотрим что нам может предложить обновлённая версия ASP.NET 4.5.1? Давайте переместимся немного назад, а именно в год 2013-ый, когда состоялся релиз Visual Studio 2013. Если кто помнит, тогда мы не получили ничего абсолютно нового в плане глобальных изменений. Да, была реализована так называемая идея объединения технологий Web Forms, MVC и Web API, получившая официальное название «Единый ASP.NET» (“One ASP.NET”), но она немножко припозднилась, точнее могли раньше сделать, ничего этому не мешало, но не делали. Конечно, технологии и библиотеки были обновлены, но в глобальном плане ничего революционного не было, за исключением новой идеи – «OWIN» и её реализации «Katana». Для получения большей информации насчёт последних рекомендую ознакомиться с циклом статей «Microsoft OWIN и конвейер обработки запросов ASP.NET». А что по сути дал нам OWIN в ASP.NET 4.5.1, ровным счётом ничего полезного. Единственное – конвейер усложнился ещё больше, хотя и без того был сложным. А сложность не является оправданной, если не приносит никакой пользы. В нижнем рисунке видна схема конвейеров, поставленная рядышком: слева – обычный конвейер ASP.NET/IIS, посередине тот же конвейер, но уже по спецификации OWIN, по сути их там два и правый – конвейер без IIS и ASP.NET.В частности можно увидеть насколько конвейер OWIN без IIS простой и легковесный (файл рисунка в более высоком разрешении можно взять отсюда).

Но почему спецификация OWIN была бесполезной и не принесла ничего нового и существенного. Просто её реализация тогда ещё была далека от совершенства, это же было началом конца монополии IIS для ASP.NET (Нужны ли нам ASP.NET и IIS?). Применение данной спецификации на IIS, как уже отметил выше не было полезным, а использование вне – затруднительным. Почему затруднительным? Да, потому, что насколько хорошей бы не была идея, её ещё нужно реализовать и «обкатить» как следует. Конечно, появилась возможность хостинга приложения вне IIS, но использовать свой сервер или хост (Self-Host) уровня обычного консольного приложения попросту неразумно для серьёзных приложений. Может мы чем-то не довольны в IIS, но все те средства администрирования (управление, диагностика, логирование и т.п.) сервера, весь тот опыт (багаж знаний) который есть уже, с этим нельзя не считаться. Всё же, именно дальнейшее развитие спецификации OWIN легло в основу ASP.NET Core. Несмотря на всё это ASP.NET 4.5.1 была обновлена и получила новую версию – ASP.NET 4.6. Следует отметить, что под ASP.NET 4.6 подразумевается весь следующий спектр технологий: Web Forms, MVC 5.x, Web API 2.x и SignalR 2.x. И на этот раз Microsoft не прекратила поддержку уже «устаревшей» технологии, а наоборот добавила очень много всего интересного и полезного. Ниже перечислен список самых важных нововведений.

Поддержка протокола HTTP/2.

Новая версия протокола HTTP добавлена в ASP.NET и в .NET Framework 4.6. Для использования HTTP/2 с ASP.NET приложение должно выполняться в Windows 10 или Windows Server 2016, важен не номер ОС, а версия IIS нужен IIS 10 или выше. Важно отметить, что пока ещё, на момент написания статьи, поддержка HTTP/2 не добавлена в ASP.NET Core, в будущем появится обязательно. HTTP/2 — это новая версия протокола HTTP, которая обеспечивает более эффективную коммуникацию (меньшее число циклов передачи-подтверждения между клиентом и сервером) и уменьшение задержки при загрузке веб-страницы для пользователей. HTTP/2 обеспечивает максимальное преимущество для веб-страниц (по сравнению со службами), так как оптимизирует запрос различных артефактов в ходе одной операции. Всю работу выполняют браузер и веб-сервер (IIS в Windows). Нет необходимости перекладывать нагрузку на пользователей. Большинство основных браузеров (новые версии) поддерживают HTTP/2, поэтому вполне вероятно, что пользователи смогут воспользоваться преимуществами протокола HTTP/2, если его поддерживает сервер. Более подробно о новом протоколе, к примеру, можно узнать по этой ссылке на Channel 9. На мой взгляд это очень существенное обновление для ASP.NET 4.6.

Добавлена поддержка .NET Compiler Platform (“Roslyn”) в ASP.NET.

По мне, ещё одно существенное улучшение. Чтобы не быть многословным, отмечу самое ванное преимущество, которое мы получаем, используя Roslyn это – скорость компиляции. Вдобавок ко всему и новые возможности языков программирования, хотя я их считаю пока ещё мало полезными. Для получения больших сведений на данный счёт можете взглянуть, например, сюда.

Прочие улучшения и обновления в ASP.NET 4.6.

Далее перечислен список менее значимых, хотя вполне себе полезных улучшений и обновлений. Были обновлены MVC 5 и Web API 2 до версии 5.2.3, сделаны мелкие улучшения и исправления ошибок. Добавлена асинхронная модель привязки в Web Forms, были обновлены элементы управления для поддержки Entity Framework 6 и обновлена библиотека Ajax Control Toolkit. Полный перечень всего вышесказанного можно найти в данной статье.Также следует отметить ещё одно улучшение, не относящееся непосредственно к платформе ASP.NET 4.6, но используемое ею, это – новый 64-разрядный JIT компилятора. В .NET Framework 4.6 представлена новая версия компилятора JIT, который имеет значительно большую производительность, чем существующий 64-разрядный компилятор JIT. Из всего вышеперечисленного видно, что изменений и улучшений не мало, что делает платформу ASP.NET 4.6 вполне себе актуальной на сегодняшний день. И конечно, улучения будут и в будущем.

А что насчёт новейшей версии – ASP.NET Core?

Кратко перечислю основные значимые особенности, которые более детально будут описаны в последующих статьях. Намного более быстрая и легковесная среда выполнения. Возможность хостинга приложений где и как вам удобно, больше нет жёсткой привязки к IIS, хотя данная возможность появилась немного раньше, но была не совсем удобной и доработанной, как уже отметил выше. Полная модульность благодаря ключевым изменениям и .NET Core. Кроссплатформенность (возможность хостинга приложений вне Windows, а в данном случае это Linux и Mac OS), как бы широко не рекламировалась, лично по мне это не ключевое изменение, хотя могу ошибаться. Трудно представить разработчика, использующего всё, и вся от Microsoft переходящего с ASP.NET на другую ОС. Хотя вполне реально, что разработчики использующие другие платформы будут использовать ASP.NET Core вне Windows. Конечно есть альтернативные и не мене достойные веб-технологии и там. Далее, возможность конфигурирования и развёртывания намного упрощена, но разработчику долгое время работавшему с XML трудно и непривычно переходить на JSON. Хотя JavaScript библиотеки и платформы уже вовсю используют подход на основе JSON и поэтому иметь подобное на серверной стороне всё же намного удобней. Иметь единый стек как для интерфейса пользователя (Web UI), так и для API намного разумней, нежели два. Правда, на мой взгляд, задача была тогда отвязать и сделать отдельную технологию для создания служб HTTP, которую можно было бы развивать отдельно от ASP.NET/IIS, но это как видно не очень-то получилось. Также были добавлены новые средства, которые упрощают процесс диагностики приложения (об этом будет отдельная статья). Всё перечисленное выше делает приложения на ASP.NET Core более «дружественным к облаку» (Cloud Optimized ASP.NET), а как известно облачные технологии уже сегодня имеют большую роль и будут иметь ещё большую в будущем. И наконец отмечу, что все перечисленные изменения появились благодаря тому, что платформа была переписана почти с нуля, благодаря уже имеющемуся опыту и сегодняшним требованиям, а это уже о многом говорит.

Название моей прошлогодней статьи «Microsoft ASP.NET vNext: эволюция или революция?» звучит слишком громко, но это вполне оправдано, если смотреть с точки зрения проделанной работы (которая на мой взгляд могла быть сделана и намного раньше), т.е. разницы с предыдущей. Да всё хорошо и замечательно, у нас много всего нового, но что нам, всем тем, кто использует данную платформу, даст новейшая технология? Ведь опыт показывает, что для построения «правильных» приложений технология уходит на второй план и в большинстве случаем не играет ключевую роль. То есть, если разработанное приложение не решает или решает плохо поставленные задачи, тогда никакая супер-мега технология, в подавляющем большинстве случаев, легко и просто не поможет кардинально исправить ситуацию. Если лет пять назад на так называемых «front-end» (замечу что под данным термином в данном случае я подразумеваю не верстальщика, а разработчика, уверенно владеющего JavaScript и разного рода библиотеками и технологиями на JavaScript) разработчиков смотрели косо, то ситуация сегодня совсем другая. Разрабатывать на JavaScript ничуть не легче и проще, а порой и ещё сложнее. JavaScript– это «душа» веба сегодня, нельзя с этим не считаться. Хотим мы того или нет, но подход, при котором HTML генерировался на сервере с помощью серверных технологий всё больше становится менее популярным, и это неизбежно и тому есть причина. Веб-приложение сегодня – это нечто намного и намного большее, чем было скажем лет десять назад. В свою очередь это влечёт за собой сложность, которая становится неоправданно высокой, если использовать серверные технологии, такие как ASP.NET Web Form или ASP.NET MVC для реализации логики работы сложного и интерактивного приложения на клиенте, вместо того же JavaScript. До сегодняшнего дня Visual Studio ничего близкого не могла предложить по сравнению, например, с тем же WebStorm (разработчики у кого есть опыт работы с WebStorm меня поймут) с точки зрения «front-end» разработки. А использовать приложение ASP.NET исключительно как сервисный слой не всегда разумно, учитывая альтернативные технологии. С приходом ASP.NET Core ситуации меняется, жаль, что не раньше, хотя функционал по работе с SPA и не только, по сравнению с WebStorm, на мой взгляд, пока ещё ограничен. Да, может я слишком критичен в последних приложениях, можно было бы обойтись существующими возможностями Visual Studio, но это жутко неудобно. К примеру, если взять тот же Gulp или Grunt, до Visual Studio 2015 и ASP.NET Core встроенных средств для работы с ними не было. Поэтому не может не радовать факт наличия много всего нового в ASP.NET Core. И так, будем прагматичны, имея две технологии для веб-разработки неизбежно возникнет вопрос:

Что нам следует сделать, каков наш выбор?

Выбор в данном случае не простой. Если у вас классическое приложение ASP.NET Web Forms и много свободных ресурсов (денег) – мигрируйте на ASP.NET Core. В случае ограниченных ресурсов, советую вам проделать постепенную миграцию до ASP.NET 4.6. Используя идею «Единый ASP.NET» это можно сделать поэтапно, где-то оставить старый код, где-то MVC, а в частях где производительность критична на клиенте и сервере тоже – подход с одностраничным приложением (SPA), например, используя AngularJS. Я со своими разработчиками делал подобное, есть опыт миграции корпоративных веб-порталов с ASP.NET 3.5 на ASP.NET 4.6. И скажу вам, что это не так просто, как вначале казалось, слишком много подводных камней (вот один из многих) было, отчасти зависящих также и от качества кода. Ну а если ваш код не удовлетворяет вашим потребностям, то тут стоит задуматься именно над этим, а не о технологии или платформе. В том случае, если у вас приложение ASP.NET MVC, переходить на ASP.NET Core стоит в двух случаях: у вашего приложения проблемы с производительностью (вы сделали всё, дальше ничего оптимизировать невозможно) или у вас много денег свободного времени. В противном случае нужно улучшать свой код. Бывают случаи, когда код сильно завязан на System.Web.dll и IIS, это тоже весомый повод ничего не трогать. Ну и последний случай, если ASP.NET используется исключительно в виде веб-сервисов, например, в случае с Web API. Примером тому могут быть одностраничные приложения (SPA) или распределённые, которые могут и не иметь отношения к HTML. В подобном случае перейти на новую версию будет намного легче, чем в предыдущих. Опять-таки, если вас всё устраивает, то переходить на ASP.NET Core незачем. Почти во всех случаях, достаточно легко и быстро обновить .NET Framework до версии 4.6 и жить спокойно. Я знаю приложения и людей, которые используют всё ещё классический ASP и пока ещё их это устраивает. Если вы не довольны производительностью Web API и IIS, то это тоже повод для обновления на ASP.NET Core.

Теперь осталось попытаться дать однозначный ответ на главный вопрос, так каков же наш выбор: ASP.NET 4.x или ASP.NET Core? Однозначного ответа нет, зависит от... И выбор за вами, однако, нужно помнить, что будущее за ASP.NET Core и рано или поздно оно наступит.

Comments

  • Anonymous
    July 24, 2015
    Статья полезная. В связи с тем что Вы многое по данной тематике видите изнутри хотел бы попросить совета. Я старый (в прямом и переносном смысле) разработчик программно - аппаратных систем, с 1973 еще года. Ассемблер, Basic, Квейсик (аппаратно - ориентированный Бейсик), Паскаль, Delphi, Matlab, PHP ... чего только не было, с 2003 кажется C#, Visual Studio, MySQL, MSSQL и все с этим связанное. Сегодня опять на распутье - множество проектов сделано на WebForms, сегодня уже на пенсии в стадии разработки собственный большой проект по тематике импорто-замещения ... многое сделано (на WebForm), но еще больше предстоит - только вот на чем? Вэб - формы как будто уходят в прошлое и причины понятны. Впереди ждут разработки на платформе ASP.NET 5. Попытался сразу, минуя MVC 5 and MVC 6  перейти на ASP.NET 5  и сразу наткнулся на невозможность создать area - в Solution add area пока не предусмотрено. Кроме того, в свое время (года 4 назад) пришел к выводу Enterprise Library 6.0 вроде как использовать более эффективно нежели EF (ныне 7 версия) - ее (EL 6.0) и использую. Что посоветуете, что сделали бы на моем месте?

  • Anonymous
    July 24, 2015
    Однозначно ответить сложно, но... "сегодня уже на пенсии в стадии разработки собственный большой проект по тематике импорто-замещения ... многое сделано (на WebForm), но еще больше предстоит - только вот на чем? " – ASP.NET 5, только учтитете, что до релиза пара месяцев примерно и ещё нужно время на переписывание существующего. "Вэб - формы как будто уходят в прошлое и причины понятны." –в целом да, но списывать со счетов его рано, учитывая существующую большую базу проектов, да и всё зависит от поставленных целей, про которые упомянул выше. " Кроме того, в свое время (года 4 назад) пришел к выводу Enterprise Library 6.0 вроде как использовать более эффективно нежели EF (ныне 7 версия) - ее (EL 6.0) и использую." – на этот счёт идут большие баталии и бесконечные холивары, лично я против применения EF в проектах интенсивно использующих СУБД.

  • Anonymous
    July 25, 2015
    The comment has been removed

  • Anonymous
    July 25, 2015
    Пока попытаюсь мигрировать сразу в ASP.NET 5 - чисто из спортивного интереса ко всему новому. Тем не менее интересно, что, на ваш взгляд, может дать ASP,NET 5 для тех кто проектирует достаточно сложный проект на MVC, но при этом не нуждается в облачных технологиях (поскольку проект закрытый (мой случай)), core (предпочтительны возможности полной версии framework) Я, честно говоря, как обычный разработчик, пока не ощущаю каких - либо принципиальных функциональных отличий ASP.NET 5 от MVC на Framework 4.6.

  • Anonymous
    July 26, 2015
    "достаточно сложный проект" – это понятие относительное, смотря что под ним подразумевается. "Тем не менее интересно, что, на ваш взгляд, может дать ASP,NET 5 для тех кто проектирует достаточно сложный проект на MVC, но при этом не нуждается в облачных технологиях (поскольку проект закрытый (мой случай)), core (предпочтительны возможности полной версии framework)" - как уже описал в статье: намного более упрощённая технология, с вытекающей оттуда производительностью и многими другими... "Я, честно говоря, как обычный разработчик, пока не ощущаю каких - либо принципиальных функциональных отличий ASP.NET 5 от MVC на Framework 4.6." - и не будете, значит "старый" вас вполне себе утраивает, поэтому не нужно переходить.

  • Anonymous
    July 27, 2015
    Проект сложный в том смысле что пока никто, ни в США, ни в ЕС, ни тем более в России не в состоянии решить триединую задачу которая решается в этом проекте и без решения которой ни о какой де-индустриализации в этих странах не может быть и речи ... Имеется ввиду следующая триединая задача - обеспечение конкуренции с Китаем (также и любыми другими конкурентами) возможно лишь при одновременном соблюдении нескольких требований: (1) обеспечение в условиях ВТО себестоимости российской  (для США - американской) продукции на уровне китайской. Большая часть российских "экспертов" сходится в том что для этого необходимо уменьшение ставки рефинансирования. При этом никто из них не в состоянии задать себе вопрос - почему нет производства в США, где ставка рефинансирования близка к нулю; (2) обеспечение проектировании технологий и миллионов наименований продукции (любой) и оборудования для их производства, с периодичностью 1-6 месяцев. Именно с такой периодичностью меняется номенклатура товаров на рынке. Все в условиях когда согласно статистике на 1 российского инженера с соответствующими средствами разработки приходится до 100 китайских и 8 американских; (3) обеспечение производства миллионов наименований продукции, устаревающей в течение 1 – 6 месяцев – это возможно лишь если оборудование способно оперативно переналаживаться на новый вид продукции, в противном случае оборудование по истечении некоторого  времени придется выкидывать на свалку; Только в этом случае можно конкурировать с миллионами наименований постоянно обновляющейся продукции Китая и третьих стран. Одновременное выполнение этих условий составляет коридор в котором должна находиться любая инновационная программа, способная обеспечить конкуренцию с Китаем. В США я близко знаком с руководителями проекта "Сократ" (в прошлом программа "Звездных войн", ныне это третья генерация, лежащего в основе H.R. 516 Return Jobs in America Act от ноября 2011 - они делают ставку на генерацию технологий, с использованием в т.ч. и средств АНБ, но пока им мало что удается - дело в том, что любые технологии копируются уже в первом образце ... Между чем триединая задача решается, правда для ее решения нужны соответствующие знания на уровне ктн в 4-х областях - организации производства, автоматизации производства, экономике - ну хотя бы на уровне бухгалтера, как выяснилось большинство "экспертов" - экономистов не знают ее (бухгалтерии) азы ... и наконец программирования, где задача намного сложнее той что реализует Гугл ...

  • Anonymous
    July 27, 2015
    Применительно к проекту, который, уверен, сложнее того, что делает Гугл представляется, что в основном в проекте должна использоваться полная система Framework, за исключением Web API, где с большой вероятностью возможно использование core.