ASP.NET vNext не зависит от хоста, что это означает?
Согласно учебнику ASP.NET vNext:vNext is host agnostic . You can host your app in IIS, or self-host in a custom process
Может ли кто-нибудь помочь мне понять это в глубине, показывая разницу между текущим хостом asp.net и новым?
2 ответа
История хостинга ASP.NET
Еще в 2002 году для платформы.NET был в основном один веб-сервер, и это был IIS. Несколько лет спустя веб-сервер разработки Visual Studio ("Кассини", ранее входивший в состав оригинальной веб-матрицы) появился в качестве сервера, предназначенного только для разработчиков. Но все они в конечном итоге использовали System.Web в качестве уровня хостинга между приложением и веб-сервером. Хост System.Web тесно связан с IIS, и его очень сложно запустить на других хостах. Даже реализация на веб-сервере VS Dev была ограничена, поскольку поддерживала только определенные функции. Таким образом, для типичных приложений ASP.NET, который зависел от System.Web, оставался только один "хост" производственного качества.
Прошло около десяти лет, и OWIN стал интерфейсом между приложениями и веб-серверами. Это позволило любому OWIN-совместимому приложению общаться через OWIN с веб-сервером, на котором был OWIN-совместимый уровень хостинга. Microsoft написала Katana как одну OWIN-реализацию, в которой могли размещаться веб-API ASP.NET, ASP.NET SignalR и многие сторонние платформы на нескольких серверах, включая IIS (и IIS Express), сервер собственного размещения Katana и пользовательские хосты (т.е. запустить хост Катаны в пользовательском приложении). Есть еще одна OWIN-реализация под названием Nowin, которая должна запускать те же приложения, что и Katana. Это пример хозяина агностицизма.
Теперь перенесемся на несколько лет назад, и появится ASP.NET vNext, который следует модели, очень похожей на OWIN, с точки зрения наличия промежуточного программного обеспечения и агностицизма хоста. ASP.NET vNext также имеет уровни совместимости для компонентов приложений промежуточного ПО OWIN.
ASP.NET vNext хост-агностицизм
ASP.NET vNext не зависит от хоста так же, как Katana и OWIN. Приложения, написанные с использованием ASP.NET vNext, знают только об уровне абстракции хоста, например IApplicationBuilder (ранее IBuilder) интерфейс. Приложения не общаются напрямую с веб-сервером. Большая часть этой абстракции выполняется через "функциональные интерфейсы", так что некоторые серверы могут реализовывать функции, а другие могут отказываться.
Варианты веб-хостинга
Приложения ASP.NET vNext могут размещаться на IIS, IIS Express, ваших собственных пользовательских EXE-файлах, на новом кроссплатформенном сервере Kestrel, и, без сомнения, в будущем появятся другие хосты.
Ни Katana, ни ASP.NET vNext не являются заменой для IIS или других хостов, хотя у них обоих есть альтернативные веб-серверы. IIS поддерживает некоторые более продвинутые функции по сравнению с Katana и ASP.NET vNext, такие как разогрев приложений, более богатое управление временем жизни приложений (т. Е. Что делать в случае сбоя приложения, контроля объема используемой памяти и других типов регулирования)., удаленное управление и пр.
Преимущества OWIN, ASP.NET vNext и независимость от хоста
Я не могу говорить о мотивах создания OWIN, потому что я никогда не был частью этой группы. Но преимуществ абстракции хоста веб-сервера много:
- Может переключаться между хостами относительно легко. Например, обычно локально запускается на сервере только для разработки, который может работать с минимальными разрешениями. Затем при развертывании в производство может быть использован более полнофункциональный хост, такой как IIS. Однако для установки IIS требуются административные разрешения, которые есть не у всех на рабочих станциях.
- Могут существовать и другие варианты хостинга. Еще в то время из-за тесной зависимости ASP.NET от IIS мог существовать только один хост, поэтому фактически не было "рынка" для других хостов.
- Определенные типы тестов легче писать, имея хост-тест в памяти. Это часто используется для тестирования всего стека веб-приложения, но без каких-либо сетевых вызовов.
Мотивации для ASP.NET vNext частично перечислены на официальном сайте ASP.NET vNext в руководстве по началу работы. Краткое резюме: иметь кроссплатформенную платформу с открытым исходным кодом, платную по ходу работы и независимую от хоста платформу для создания веб-приложений и сервисов. Похоже, некоторые маркетинговые вещи, но это все ключевые аспекты системы. NodeJS предлагает в значительной степени тот же самый точный набор функций, хотя, разумеется, если вы посмотрите на детали, вы обнаружите множество различий в реализации и, несомненно, некоторые более глубокие философские различия. Мотивация для поддержки этих функций, как правило, не требует пояснений.
Аудитория для ASP.NET
Обратите внимание, что речь идет об аудитории ASP.NET в целом, которая включает в себя все: от веб-форм ASP.NET до MVC, веб-API, SignalR, Katana и ASP.NET vNext. Любая из этих платформ подходит для любого проекта и должна использоваться любым достаточно опытным разработчиком. Это видно по размерам проектов, которые их используют. Этот самый сайт (Stackru.com) частично построен с использованием ASP.NET MVC некоторыми очень продвинутыми разработчиками (я полагаю), но есть много гораздо меньших сайтов, использующих MVC, созданных относительными новичками. ASP.NET vNext является будущей версией большинства этих же сред и, как таковая, предназначена для приложений того же типа и разработчиков того же типа.
Дополнительная информация
Дополнительную информацию о ASP.NET vNext и OWIN можно найти в блоге одного из разработчиков: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/
Помня о том, что vNext по-прежнему является очень ярким быстродвижущимся объектом, поскольку в настоящее время дела обстоят так, это своего рода "наполовину" независимый хост.
Спецификация промежуточного программного обеспечения, которую он определяет и применяет, допускает очень общий интерфейс для организации программ. Таким образом, ваш путь развития одинаков. Но приложения vNext сами по себе являются серверами и, как ни странно, в настоящее время обязаны включать библиотеки склеивания для типа используемого вами сервера.
Вы можете наблюдать это, видя, что вы должны указать, какой тип сервера вы хотите использовать внутри project.json файл. Если бы проекты vNext были действительно независимыми, вы бы выбрали сервер на системном уровне и указали бы, смонтировали или запустили ваше приложение с выбранного сервера.
Это несколько сложно из-за задействованных жизненных циклов, после того как вы закончите здесь, я призываю вас перейти к этой проблеме github в проекте vNext, где я пытаюсь отстаивать действительно отделенный дизайн.