Далее подробно объяснена архитектура запроса ASP.NET.
Введение
Большинство разработчиков знакомы с высокоуровневыми абстракциями, предоставляемыми ASP.NET, такими как веб-формы и веб-службы. Однако под этими абстракциями находится очень интересная и продвинутая архитектура. Знание внутренностей этой архитектуры не только повышает уровень ASP.NET разработчика, но и помогает ему писать лучше спроектированные приложения и решать сложные проблемы, возникающие значительно ниже высокого уровня, используемого ASP.NET.
Данная статья изучает, как ASP.NET (и IIS) обрабатывает запросы. Подробно рассмотрено, что происходит внутри архитектуры ASP.NET с момента ухода запроса из браузера до того, как он пройдет сквозь среду выполнения ASP.NET.
Замечание: После того как запрос покинет среду выполнения ASP.NET, начинает выполняться модель страницы ASP.NET. Это выходит за рамки данной статьи, но будет темой следующей статьи.
Браузер выдает запрос
Процесс начинается, как только пользователь запросит ресурс ASP.NET посредством браузера. Например, пользователь запросил следующий URL: http://www.myserver.com/myapplication/mypage.aspx. Запрос достигнет “myserver”, где установлены Windows Server 2003 и IIS 6.0.
Что лучше ASP.NET или ASP.NET Core?
Драйвер http.sys режима ядра перехватывает запрос
Как только запрос достигает IIS, запрос обнаруживается драйвером режима ядра http.sys. Дальше рассказано, что такое драйвер режима ядра http.sys и что он делает.
В общем, Windows предоставляет два режима: режим пользователя и режим ядра. Пользовательские приложения работают в режиме пользователя, а код операционной системы работает в режиме ядра. Если пользовательскому приложению надо работать непосредственно с оборудованием, эту конкретную операцию выполняет процесс режима ядра. Очевидное назначение этих режимов – защитить компоненты операционной системы от повреждения пользовательскими приложениями. Теперь, когда ясно, что такое режим пользователя и режим ядра, в чем заключается роль драйвера режима ядра http.sys?
При создании нового веб-сайта IIS IIS регистрирует сайт в http.sys, который далее получает все запросы HTTP для любого веб-приложения внутри сайта. http.sys работает как ретранслятор, направляя запросы HTTP процессу режима пользователя, выполняющего веб-приложение. В данном случае процесс режима пользователя является рабочим процессом, выполняющим пул приложений, в котором работает веб-приложение. http.sys реализует механизм ведения очередей, создавая столько очередей, сколько пулов приложений имеется в IIS.
Продолжая пример, как только запрос достигает “myserver”, http.sys перехватывает запрос. Допустим, “myapplication” настроено на работу в пуле приложений “myapplicationpool”; в таком случае http.sys проверяет очередь запросов “myapplicationpool” и пересылает запрос рабочему процессу, в котором работает “myapplicationpool”.
Запрос пересылается пулу приложений
Запрос пересылается пулу приложений, как сказано выше. Каждым пулом приложений управляет экземпляр рабочего процесса “w3wp.exe”. По умолчанию “w3wp.exe” выполняется под учетной записью “NetworkService”. Это можно изменить следующим образом: щелкнуть правой кнопкой мыши по пулу приложений, вмещающему приложение—Свойства—вкладка Идентичность.
Что такое ASP.NET
Вспомните, что пулом приложений управляет рабочий процесс “w3wp.exe”. Сейчас рабочий процесс берет управление на себя.
Рабочий процесс загружает ASP.NET ISAPI
Рабочий процесс “w3wp.exe” ищет URL запроса, чтобы загрузить нужное расширение ISAPI. Запрошенный ресурс в URL — “mypage.aspx”. Что происходит дальше? Полный разбор расширений ISAPI (и фильтров) не входит в статью, но вкратце, расширения ISAPI являются способом, посредством которого IIS обрабатывает запросы на разные ресурсы.
После установки ASP.NET он устанавливает свое собственное расширение ISAPI (aspnet_isapi.dll) и добавляет привязку в IIS. IIS увязывает разные расширения с их расширениями ISAPI. Привязки в IIS можно посмотреть так: щелкнуть правой кнопкой мыши по веб-сайту-Свойства-вкладка Домашний каталог-кнопка Конфигурация-вкладка Привязки. Рисунок ниже показывает привязки:
Как видно, расширение “.aspx” увязано с расширением aspnet_isapi.dll. Рабочий процесс передает запрос расширению aspnet_isapi. Расширение aspnet_isapi, в свою очередь, загружает среду выполнения HTTP, и начинается обработка запроса.
Перед изучением того, что происходит внутри среды выполнения HTTP, рассмотрены детали того, как рабочий процесс загружает веб-приложение. Рабочий процесс загружает сборку веб-приложения, выделяя один домен приложения для приложения. Когда рабочий процесс запускает веб-приложение (в его домене приложения), веб-приложение наследует идентичность процесса (NetworkService по умолчанию), если перевоплощение запрещено. Но если перевоплощение разрешено, каждое веб-приложение работает под учетной записью, аутентифицированной IIS, или под учетной записью пользователя, настроенной в web.config.
• Identity impersonate=»true»
o Если IIS разрешает только анонимный доступ, переданной веб-приложению идентичностью будет [machine]IUSR_[machine].
o Если только встроенная аутентификация Windows разрешена в IIS, переданной веб-приложению идентичностью будет аутентифицированный пользователь Windows.
o Если разрешены встроенная аутентификация Windows и анонимный доступ, переданная веб-приложению идентичность будет зависеть от той, которая была аутентифицирована IIS. IIS сначала пытается использовать анонимный доступ, чтобы предоставить пользователю доступ к ресурсу веб-приложения. Если эта попытка проваливается, то он пытается использовать аутентификацию Windows
• Identity impersonate=»true» username=»username» password=»password»
o Позволяет веб-приложению работать под конкретной идентичностью.
Замечание: IIS 6.0 и IIS 5.0 по-разному обрабатывают запросы. Режим ядра http.sys реализован только в IIS 6.0. Такого свойства у IIS 5.0 нет. В IIS 5.0 запрос перехватывается непосредственно модулем aspnet_asapi, передающим запрос рабочему процессу. Рабочий процесс и модуль ISAPI взаимодействуют посредством конвейеров, приводя к издержкам вызова.
Более того, один экземпляр рабочего процесса обслуживает все веб-приложения; нет пулов приложений. Модель IIS 6.0 намного лучше модули IIS 5.0. Рабочим процессом в IIS 5.0 является “aspnet_wp.exe”, в отличие от “w3wp.exe” в IIS 6.0. Рабочий процесс “aspnet_wp.exe” работает под стандартной учетной записью “ASPNET”, в отличие от “NetworkService” в IIS 6.0. Можно изменить эту учетную запись, найдя элемент в файле “machine.config”.
Замечание: IIS 7.0 предоставляет два способа обработки запросов ASP.NET. Первый – классический способ, работающий так же, как в IIS 6.0; полезен для совместимости. Второй – новый комплексный способ, в котором ASP.NET и IIS входят в один и тот же конвейер обработки запроса. Во втором способе модули и обработчики .NET подключаются непосредственно к общему конвейеру обработки запроса, что эффективней способа IIS 6.0.
В среду выполнения HTTP
Обобщено, что пока произошло: запрос был передан от браузера к http.sys, передавшему запрос пулу приложений. Рабочий процесс, управляющий пулом приложений, изучает URL запроса и использует привязку расширения приложения IIS для загрузки ASP.NET ISAPI “aspnet_isapi.dll”. ASP.NET ISAPI загружает среду выполнения HTTP, также называемую средой выполнения ASP.NET.
Начинается изучение того, что происходит внутри HTTP. Точка входа среды выполнения — класс HttpRuntime. Метод HttpRuntime.ProcessRequest сообщает о начале обработки. В следующих подразделах рассмотрено, что происходит внутри среды выполнения после вызова метода ProcessRequest:
Создается новый экземпляр HttpContext запроса
HttpContext существует в течение времени жизни запроса и доступен через статическое свойство HttpContext.Current. Объект HttpContext представляет контекст активного сейчас запроса, так как он содержит ссылки на объекты, к которым можно обратиться в течение времени жизни запроса, а именно Request,Response, Application, Server и Cache. В любой момент при обработке запроса HttpContext.Current дает доступ ко всем перечисленным объектам. Более того, объект HttpContext содержит коллекцию Items, которую можно использовать для хранения специфичной информации запроса.
HttpRuntime советует классу HttpApplicationFactory загрузить объект HttpApplication
Класс HttpApplicationFactory создает пул объектов HttpApplication для приложения ASP.NET и связывает каждый запрос с объектом HttpApplication из того пула. Если в момент запроса в пуле нет объектов, то HttpApplicationFactory создает объект и передает его запросу. В результате запрос направляется приложению, работающему в пространстве AppDomain, и объект HttpApplication назначается для запроса.
Теперь, когда ясно, что происходит, возникает вопрос, зачем нужен объект HttpApplication. HttpApplication – внешний контейнер для конкретного веб-приложения, увязанный с классом, определенным в Global.asax. При изучении файла Global.asax выясняется, что он унаследован от класса System.Web.HttpApplication.
Есть набор предопределенных событий, возбуждающихся в течение времени жизни запроса; эти события представлены в файле Global.asax. HttpApplication служит контроллером этих событий. К тому же, HttpApplication хранит список сконфигурированных HttpModules, загружаемых динамически в ходе обработки запроса. Где выполняются эти события и HttpModules и чем именно являются HttpModules и HttpHandlers? Ответы на эти вопросы находятся внутри конвейера HTTP:
Внутри конвейера HTTP
Конвейер HTTP является, как намекает имя, конвейером для обработки запроса. Он называется конвейером, потому что содержит набор HttpModules, перехватывающих запрос на пути к HttpHandler. HTTPModules являются классами, имеющими доступ к входящему запросу. Эти модули проверяют входящий запрос и принимают решения, влияющие на внутренний поток запроса. Пройдя через заданные HTTPModules, запрос достигает обработчика HTTP, чьей задачей является генерация вывода, отправляемого обратно запрашивающему браузеру.
Запрос проходит через модули HTTP
HttpModules конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). В ASP.NET есть много встроенных HttpModules, осуществляющих доступ к запросу и выполняющих разные функции. Этими HttpModules являются аутентификация, управление состоянием и модули кеширования. ASP.NET 2.0 добавляет дополнительные модули, а именно членство, управление ролями и персонализация. Рисунок ниже взят из файла “machine.config” и показывает, как определены встроенные модули:
Разработчики могут написать свои собственные модули и подключить их в “machine.config”, чтобы применить модули ко всем приложениям, или в “web.config” конкретного приложения, чтобы применить модули только к нему. Запросы внутри конвейера HTTP проходят через все модули, определенные в “machine.config” и “web.config”. Как сказано в предыдущем разделе, эти модули хранятся внутри HttpApplication и динамически загружаются при выполнении.
Запрос попадает в обработчик HTTP
Обработчики HTTP являются конечными точками в конвейере HTTP. Задача обработчика HTTP – сгенерировать вывод для запрошенного ресурса. Для страниц ASPX это означает перевод страниц в HTML и возврат этого HTML. Обработчики HTTP конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). Рисунок ниже взят из “machine.config” и показывает, как устанавливаются обработчики HTTP.
Как видно на рисунке выше, разные ресурсы настраиваются на использование разных обработчиков. Страницы ASP.NET ASPX настроены на использование “PageHandlerFactory”. Задача “PageHandlerFactory” – предоставить экземпляр HTTP, способный обработать запрос. “PageHandleFactory” пытается найти скомпилированный класс, представляющий запрошенную страницу “mypage.aspx”.
В случае успеха он передает данный скомпилированный класс в качестве обработчика HTTP. Если нет скомпилированного класса, представляющего запрошенную страницу, потому что запрос первый или потому что страницу изменили с момента последнего запроса, то “PageHandlerFactory” компилирует запрошенную страницу “mypage.aspx” и возвращает скомпилированный класс. Все последующие запросы будут обслуживаться тем же самым скомпилированным классом, пока страницу не изменят.
Возникает вопрос, почему “PageHandlerFactory” возвращает экземпляр скомпилированного класса, выступающий обработчиком запроса. Является ли скомпилированным класс фактическим обработчиком HTTP? Ответ очевиден из изучения отделенного кода страницы, “mypage.aspx.cs”. Страница унаследована от класса “System.Web.UI.Page”; этот класс реализует интерфейс “IHttpHandler”, что делает его пригодным в качестве обработчика HTTP.
Замечание: Компиляция страницы не входит в эту статью, но будет описана в следующей статье, рассматривающей модель страницы ASP.NET.
Начинается выполнение страницы
Наконец, запрос был передан нужному обработчику HTTP. Далее среда выполнения вызывает метод IHttpHandler.ProcessRequest, и начинается жизненный цикл страницы ASP.NET. Происходящее далее не входит в эту статью и будет подробно объяснено в следующей статье.
Вывод
Данная статья рассмотрела скрытые детали того, что происходит при каждом запросе страницы ASP.NET через браузер. Чтобы быстро обобщить процесс:
• Запрос на “mypage.aspx” веб-приложения “myapplication” выдается из браузера
• Запрос достигает IIS и перехватывается драйвером http.sys
• Драйвер http.sys пересылает запрос пулу приложений, на работу в котором настроено “myapplication”
• Рабочий процесс пула приложений “w3wp.exe” загружает ASP.NET ISAPI “aspnet_isapi.dll”, изучая URL и увязывая расширение “.aspx” с “aspnet_isapi” (эти расширения определены в IIS)
• ISAPI “aspnet_isapi” загружает среду выполнения HTTP
• Среда выполнения HTTP создает HttpContext и связывает запрос с HttpApplication
• Запрос проходит через конвейер HTTP
• Модули HTTP выполняются для запроса, пока запрос не попадет в обработчик HTTP страницы ASP.NET
• Как только запрос покидает конвейер HTTP, начинается жизненный цикл страницы
Источник: www.cyberguru.ru
Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.
Microsoft .NET Framework — это платформа для создания, развертывания и запуска Web-сервисов и приложений. Она предоставляет высокопроизводительную, основанную на стандартах, многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующего поколения, а также решать задачи развертывания и использования интернет-приложений. .NET Framework состоит из трех основных частей — общеязыковой среды выполнения (common language runtime), иерархического множества унифицированных библиотек классов и компонентной версии ASP, называемую ASP.NET.
ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты.
Вы также можете использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей вашего сайта. В общем, возможности ASP.NET ограничены только вашим воображением.
Давайте обсудим, что такое динамические страницы HTML и чем они отличаются от статических. Статическая страница содержит код на языке гипертекстовой разметки HTML. Когда автор страницы пишет ее, он определяет, как будет выглядеть страница для всех пользователей страницы. Содержание страницы будет всегда одинаковым независимо от того, кто и когда решит ее просмотреть.
Языка HTML вполне достаточно для отображения информации, которая редко изменяется и не зависит от того, кто ее просматривает. Страница HTML — простой ASCII-текст, следовательно, клиент может работать в любой операционной системе.
Совершенно понятно, что если сформировать web-страницу, описав ее структуру средствами HTML, она будет совершенно статична в смысле содержимого. То есть при просмотре в браузере она будет нести в себе точно ту же информацию, что была в нее записана в момент создания, и переданные пользователем данные не могут быть использованы для модификации содержимого отображаемых ему страниц: он сможет увидеть только то, что предварительно было записано в конечный набор файлов.
Динамическими принято называть web-страницы, которые перед отправкой клиенту проходят цикл обработки на сервере. В самом простом случае это может быть некоторая программа, которая модифицирует запрашиваемые клиентом статические страницы, используя параметры полученного запроса и некоторое хранилище данных. Даже при такой примитивной организации «неразрешимая» задача из предыдущего абзаца обретает очевидное решение: достаточно подготовить всего одну статическую страницу – шаблон – и перед отправкой страницы программно подставлять в него значение, полученное сегодня из банка или метеобюро.
Большинство страниц на ранних стадиях развития интернета были статическими. Последние 10 лет растет количество динамических страниц. И это понятно, пользователи интернет хотят не только читать готовую информацию, а быть активными действующими лицами. Например, они заказывают товары в интернет-магазине, пишут дневники, участвуют в конкурсах.
Информационные порталы обновляют новости каждую минуту. Динамические страницы могут подстраиваться под конкретного пользователя, а также реагировать на его действия в браузере. Каким же образом? Для этого придумано множество технологий. Например, того, чтобы идентифицировать пользователя и сохранить его настройки для данного сайта, применяются файлы-cookies.
Существуют языки, способные динамически изменять содержимое веб-страницы. С одной стороны, это языки скриптов, выполняющиеся непосредственно у клиента. Примеры скриптовых языков — JavaScript и VBScript. Скрипты на этих языках встроены в код HTML, который сервер посылает браузеру.
Сценарии, выполняемые на стороне клиента, выделяются тегами и . Браузер интерпретирует этот код и показывает пользователю результат. Сам код можно просмотреть через View Source браузера. Естественно, эти программы не могут быть большими. Например, если нужно выполнить поиск в базе данных, мы не может отправить пользователю все ее содержимое.
Но скрипты могут проверить правильность запроса, введенного в форму, тогда не придется перезагружать сервер обработкой неправильных запросов. Некоторые программисты создают на JavaScript анимационные эффекты. Одна студентка intuit.ru желала найти скрипт, который бы отправлял SMS-сообщения. Увы, это невозможно.
Выполняемых на стороне клиента сценариев недостаточно для создания полноценных динамических страниц. Даже если на странице используется JavaScript, анимированные картинки .gif, она называется статической.
Динамическая веб-странице должна быть создана «на лету» программой, исполняющейся на интернет-сервере. Широко применяются механизм шлюзов CGI(Common Gateway Interface). Вначале пользователь получает статическую страницу с формой. Вам известно, что в теге FORM существует атрибут ACTION. Именно он задает адрес (URL) исполняемого приложения.
На сервере находятся исполняемые файлы программ, написанных, например на C/С++ или Дельфи, которые по протоколу HTTP принимают данные из входного потока или из переменных окружения и записывают в стандартный выходной поток готовую страницу.
Пользователю в ответ на запрос посылается HTML код, который был специально сгенерирован для него. Это может быть, например, результат поиска в поисковой системе. CGI -скрипты могут быть написаны на интерпретируемом языке (Perl) или даже скрипте командной строки. Входной и выходной потоки переназначаются. На вход интернет-сервер принимает данные, введенные пользователем.
После обработки полученных данных, пользователю возвращается результирующая страница. При исполнении cgi-программа загружается в память сервера, а при завершении – удаляется. Когда 100 клиентов одновременно обращаются к серверу, в памяти создаются 100 процессов, для размещения кода каждого из которых нужна память. Это отрицательно сказывается на масштабируемости. Напомним, что масштабируемость — это возможность плавного роста времени ответа программной системы на запрос с ростом числа одновременно работающих пользователей.
Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера.
Это позволяет повысить производительность и масштабируемость.
ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.
У ISAPI тоже есть недостатки, относящиеся к разработке. Если мы меняем исходный код dll, мы должны его откомпилировать и поместить в исполняемую директорию сервера. Но так как предыдущий вариант dll находится в памяти, необходимо остановить сервер, чтобы получить доступ на изменение файла. В это время клиенты не смогут получить в сервера ни один документ, и, конечно, будут не удовлетворены.
Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.
Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.
Пример файла asp:
Hello ASP World!
Этот код генерирует ASP!”) next i %>;
Источник: www.internet-technologies.ru
Путь ASP.NET Core [уровень 1] Основы
ASP.NET Core — новейший фреймворк для кроссплатформенной веб разработки. Пока его популярность (как и количество вакансий) только начинает набирать обороты самое время узнать о нем побольше. Ну а для того, чтобы все знания не испарились сразу после прочтения — добавим существенную практическую часть. Создадим простое приложение, для тестирования прочитанного.
Если вы считаете, что уже достаточно круты в новом фреймворке — можете попробовать пройти тест до того, как прочтете статью. Линк. Весь код проекта можно посмотреть на гитхабе.
Первая часть включает:
- Что такое .NET Core и ASP.NET Core?
- Основы создания приложения и его структура
- Добавление новых элементов, скаффолдинг
- Основы встроенного Dependency Injection
- Деплоймент в Azure
Разберемся в терминах. Один из наиболее не понятных моментов — это зависимость между старым фреймворком ASP.NET MVC и новым ASP.NET Core, а также в чем отличия .NET и .NET Core. Начнем с последнего. .NET Core — это общая платформа для разработки программного обеспечения. Фактически это еще одна реализация стандарта .NET (другие реализации — .NET, Mono). Отличия и особенности этой реализации (.NET Core) в том, что она:
- С открытым исходным кодом
- Кроссплатформенная
- Гибкая в установке — может быть внутри приложения и можно поставить несколько версий на одной и той же машине
- Все сценарии работы поддерживаются с помощью консольных инструментов
В чем же тогда особенности и отличия ASP.NET Core от предыдущего ASP.NET? Некоторые из них это:
- Возможность намного лучше контролировать нужные модули, сборки. Например, нет жесткой привязки к IIS, System.Web.dll
- Встроенный функционал для внедрения зависимостей
- Открытый исходный код
public class Program < public static void Main(string[] args) < var host = new WebHostBuilder() .UseKestrel() .UseStartup() .Build(); host.Run(); > > public class Startup < public void ConfigureServices(IServiceCollection services) < >public void Configure(IApplicationBuilder app) < >>
Класс Statup можно, в какой-то степени, охарактеризовать как новый вариант Global.asax (Это класс для глобальной настройки всего приложения в предыдущей версии ASP.NET). Грубо говоря, можно сказать, что метод ConfigureServices нужен для конфигурации контейнера для внедрения зависимостей и его сервисов, а метод Configure для конфигурации конвейера обработки запросов.
Приступим к практической реализации
Для того, чтобы лучше понять все новшества, создадим ASP.NET Core приложение на основе .NET Core.
Чтобы облегчить себе жизнь, выберем Web Application и поменяем аутентификацию на Individual User Accounts. Таким образом Visual Studio уже сгенерирует весь нужный код для базового приложения.
Рассмотрим детальней что же нового появилось в ASP.NET Core. С точки зрения разработки вся концепция осталась прежней. Структура проекта базируется на паттерне MVC. Для работы с данными по умолчанию используем Entity Framework, логика описана в классах-контроллерах, на уровне представлений используем синтаксис cshtml + новая фишка tag helpers.
Проверим классы Program.cs и Startup.cs, они действительно выглядят такими же, как было описано выше. Конечно класс Startup не совсем пуст, а уже вмещает функционал для считывания конфигурации, настройки базового логирования, маршрутизации и привязку на нашу модель базы данных.
Дополним модель базы данных сущностями для создания и прохождения тестов. Будем использовать следующие сущности: Набор тестовых вопросов — TestPackage, Сам вопрос (тест) — TestItem, Результат теста — TestResult. Пример можно посмотреть тут. Радует, что EntityFramework Core уже поддерживает большинство функционала и можно полноценно пользоваться Code First миграциями.
Добавляем логику
Теперь, когда у нас есть модель базы данных, мы можем приступить к созданию логики для нашего приложения. Самый простой способ создания админки — это механизм scaffolding. Для этого, кликаем правой кнопкой мыши по папке контроллеров и выбираем Add → New Scaffold Item:
Выбираем «MVC Controller с представлениями, с использованием Entity Framework». Этот шаблон позволяет нам быстро создать контроллер и вьюхи для управления одной конкретной моделью. Проделаем такой трюк для TestPackage и TestItem. В результате у нас есть готовый прототип админки для нашей системы.
Можно запустить проект и зайти на страницы этих контроллеров, просто добавить его имя без слова Controller в конец адреса, например, /testpackages. Конечно в ней еще не все идеально, поэтому нужно допилить некоторые моменты и сделать их более удобными.
После создания модели и простого функционала для работы с ней, можно перейти к самому процессу прохождения тестов. В общем, все выглядит просто. Сервер присылает вопрос, варианты, мы отсылаем назад ответ. Сервер сохраняет его. В конце теста показываем результат.
Добавим код для этого поведения.
В общем, все что нужно для теста у нас есть.
Основы Dependency Injection в ASP.NET Core
Важным новшеством новой версии ASP.NET так же является встроенный механизм внедрения зависимостей. В 2016 году уже никого не удивишь тем, что механизм внедрения зависимостей можно перенести внутрь фреймворка. Мало какое серьёзное приложение пишут без использование этого подхода. DI в ASP.NET Core реализован достаточно базово, но в то же время позволяет решить большинство задач управления зависимостями.
Конфигурация контейнера осуществляется в методе ConfigureServices класса Startup. Пример:
// Add framework services. services.AddDbContext(options => options.UseSqlServer(Configuration.GetConnectionString(«DefaultConnection»))); services.AddIdentity>() .AddEntityFrameworkStores() .AddDefaultTokenProviders(); services.AddMvc(); // Add application services. services.AddTransient(); services.AddTransient();
Можно заметить, что для контекста базы данных и Identity фреймворка есть дополнительные, не типичные методы их регистрации. Это позволяет более гибко их сконфигурировать. В этот подход регистрации сервисов очень красиво вписываются extension-методы.
После регистрации сервисов, самый легкий способ получить из в коде (например, в контроллерах) — это просто добавить параметр конструктора типа, который был зарегистрирован. Такие контроллеры по умолчанию создаются скаффолдингом.
Деплой
Одним из самых простых способов деплоймента остается Microsoft Azure. Нам достаточно самых базовых настроек для полноценной работы. Развертывание сайта на сервере все так же просто — с помощью нескольких кликов, начиная с контекстного меню на файле проекта.
Выводы
Пока не известно будущее «классического» .NET фреймворка, так как он, все же, является более стабильным и проверенным, поэтому может существовать еще довольно долго (привет, Python 2), хотя возможна и ситуация быстрой миграции большинства девелоперов на Core версии (не такой уже .NET и старый — 14 лет всего лишь).
Очень радует стабильность текущей версии фреймворков и инструментов. Хотя они и не идеальны, но главное, что можно полноценно писать код. Фреймворки Microsoft, как всегда, подкупают тем, что если ты был знаком с предыдущей версией, то уже знаешь больше половины следующей. Для хорошего ASP.NET девелопера, можно начинать писать на Core вообще не читая документацию, хотя многие вещи будут не понятны. Правда потом, сложно писать на обычном ASP.NET, к хорошему быстро привыкают.
Также удивляет количество вопросов на StackOverflow. Вопросы, что касаются основных вещей уже отлично гуглятся с приставкой ASP.NET Core. Часто ответы на них ведуть на Github и на дискуссии разработчиков самого фреймворка, что для мира .NET является совсем новым опытом. Очень необычными и интересным.
Источник: habr.com