Многие из вас должны знать, что выход ASP.NET MVC 5 ознаменовался переходом на новую систему авторизации под названием ASP.NET Identity. Разработчики фреймворка настоятельно рекомендуют переходить на новую систему, называя основными ее преимуществами возможность внедрения в абсолютно любой проект (ASP.NET MVC, Web Forms, Web Pages, Web API и SignalR), простую социальную интеграцию, работу на OWIN, установку и обновление посредством NuGet и другие. Присмотревшись внимательнее к ASP.NET Identity, можно без зазрения совести сказать, что это — следующий этап в развитии веб-программирования на ASP.NET. В данном посте я размещу простой туториал для начала работы с ASP.NET Identity.

Введение

На Хабре много раз затрагивалась тема OWIN, однако до сих пор то и дело всплывают вопросы о реализации приложений и компонентов с помощью OWIN. В данной публикации я начну со стандартного шаблона Visual Studio 2013 и продемонстрирую реализацию архитектуры приложения. Также я покажу, как использовать один DI-контейнер — как для MVC, так и для WebApi в рамках одного проекта.

Мы продолжаем нашу колонку по теме ASP.NET5 публикацией от Станислава Бояринцева (@masterL) — разработчика корпоративных веб-систем из компании ItWebNet. В этой статье Станислав очень подробно и интересно рассказывает о механизме маршрутизации в ASP.NET5. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

Как была организована система маршрутизации до ASP.NET 5

Маршрутизация до ASP.NET 5 осуществлялась с помощью ASP.NET модуля UrlRoutingModule. Модуль проходил через коллекцию маршрутов (как правило объектов класса Route) хранящихся в статическом свойстве Routes класса RouteTable, выбирал маршрут, который подходил под текущий запрос и вызывал обработчик маршрута, который хранился в свойстве RouteHandler класса Route — каждый зарегистрированный маршрут мог иметь собственный обработчик. В MVC-приложении этим обработчиком был MvcRouteHandler, который брал на себя дальнейшую работу с запросом.

Выражаем благодарность за подготовку статьи Павлу Ковтуну — CEO Mycroft Assistant. Павел больше 12 лет
специализируется в области автоматизации бизнеса и supply chain management.Является автором уникальных методик анализа и принятия решений в SCM, создатель первой инновационной системы управления запасами экспертного уровня.

Вступление от переводчика

Данная статья является переводом ASP.NET 5 — A Deep Dive into the ASP.NET 5 Runtime — введения в архитектуру DNX и построенного на нем ASP.NET 5. Так как оригинальная статья была написана в марте 2015 года, во время, когда ASP.NET 5 был еще в стадии активной разработки (примерно beta 3), многое в ней устарело. Поэтому при переводе вся информация была актуализирована до текущей версии ASP.NET 5 (RC1), также были добавлены ссылки на связанные ресурсы (в основном на docs.asp.net) и исходный код на GitHub (смотрите только в случаях, если вам интересна реализация). Приятного погружения!

.NET Runtime Environment (DNX)

ASP.NET 5 базируется на гибком, кроссплатформенном runtime, который может работать с разными .NET CLR (.NET Core CLR, Mono CLR, .NET Framework CLR). Вы можете запустить ASP.NET 5 используя полный .NET Framework или можете запустить используя новый .NET Core ^docs, который позволяет вам просто копировать все необходимые библиотеки вместе с приложением в существующее окружение, без изменения чего-либо еще на вашей машине. Используя .NET Core вы также можете запустить ASP.NET 5 кроссплатформенно на Linux ^docs и Mac OS ^docs.

Инфраструктура позволяющая запускать и исполнять приложения ASP.NET 5 называется .NET Runtime Environment ^docs или кратко DNX. DNX предоставляет все что необходимо для работы .NET приложений: host process, CLR hosting логику, обнаружение управляемой Entry Point и т.д.

Логически архитектура DNX имеет пять слоев. Я опишу каждый из этих слоев вместе с их обязанностями.
Изображение взято из статьи DNX-structure ^wiki

Мы рады поделиться с вами очередной статьей из серии статей о платформе ASP.NET Core (ранее ASP.NET 5). В этот раз Вячеслав Бобик — .NET-разработчика из компании Radario, продолжит свой рассказ о платформе рассказом про применение технологий OWIN, Katana и связанные вопросы. Все статьи цикла вы всегда можете найти тут #aspnetcolumn — Владимир Юнев

Немного истории

В далекие времена, когда только появился ASP.NET MVC версии CTP, никто и не задумывался, о кроссплатформености, о том, что было бы здорово запускать приложения, написаные на этом фрейворке, не только на IIS, но и на другом вэб-сервере, и на другой ОС.
Со временем, богатство фреймворка ASP.NET MVC росло, росла и монолитная библиотека System.Web, от которой зависит фреймфорк и увеличивалась его сложность. В какой-то момент, а именно с четвертой версией, этот фрейворк стал довольно большим, почти прибитым гвоздями к IIS.

С другой стороны, был ASP.NET Web API, который не имел прямых зависимостей на событийную модейль IIS, и мог хостится самостоятельно без IIS(self-hosting). В какой-то момент к ребятам из Microsoft пришло понимание, того, что нужен инстумент позволяющий возможность запускать вэб-приложения написанные на .Net не только на IIS, но и на других вэб-серверах, а так же обеспечивать возможноть гибко встраиваться в процесс обработки запросов. В итогде появилась спецификация OWIN и проект Katana.

Целью данной статьи является поиск рабочего решение, которое позволяет иметь единый контейнер зависимостей (IoC контейнер) на протяжении всего жизненного цикла запроса, контролировать его создание и уничтожение.