Что такое net core

Путь ASP.NET Core [уровень 1] Основы

ASP.NET Core — новейший фреймворк для кроссплатформенной веб разработки. Пока его популярность (как и количество вакансий) только начинает набирать обороты самое время узнать о нем побольше. Ну а для того, чтобы все знания не испарились сразу после прочтения — добавим существенную практическую часть. Создадим простое приложение, для тестирования прочитанного.

Если вы считаете, что уже достаточно круты в новом фреймворке — можете попробовать пройти тест до того, как прочтете статью. Линк. Весь код проекта можно посмотреть на гитхабе.

Первая часть включает:

В чем же тогда особенности и отличия ASP.NET Core от предыдущего ASP.NET? Некоторые из них это:

Класс Statup можно, в какой-то степени, охарактеризовать как новый вариант Global.asax (Это класс для глобальной настройки всего приложения в предыдущей версии ASP.NET). Грубо говоря, можно сказать, что метод ConfigureServices нужен для конфигурации контейнера для внедрения зависимостей и его сервисов, а метод Configure для конфигурации конвейера обработки запросов.

Приступим к практической реализации

Чтобы облегчить себе жизнь, выберем 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. Пример:

Можно заметить, что для контекста базы данных и Identity фреймворка есть дополнительные, не типичные методы их регистрации. Это позволяет более гибко их сконфигурировать. В этот подход регистрации сервисов очень красиво вписываются extension-методы.

После регистрации сервисов, самый легкий способ получить из в коде (например, в контроллерах) — это просто добавить параметр конструктора типа, который был зарегистрирован. Такие контроллеры по умолчанию создаются скаффолдингом.

Деплой

Одним из самых простых способов деплоймента остается Microsoft Azure. Нам достаточно самых базовых настроек для полноценной работы. Развертывание сайта на сервере все так же просто — с помощью нескольких кликов, начиная с контекстного меню на файле проекта.

Выводы

Источник

gosha20777

February 22, 2018 | 17 Minute Read

.NET Core

Пример 1

Для начала создадим и запустим консольное приложение Hello World (я буду использовать PowerShell для Windows, но в Bash для macOS или Linux все делается аналогично).

Давайте переместим часть логики в библиотеку классов. Для этого в дополнение к проекту hello создадим проект библиотеки классов.

Здесь мы хотим описать логику, которая будет формировать сообщение Hello World. Поэтому изменим содержимое файла Class1.cs на следующее:

Обновление файла Program.cs для дальнейшего использования класса HelloWorld:

Добавление теста в файл UnitTest1.cs:

Пример 2

Рассмотрим более интересный пример: создадим простой веб-сайт ASP.NET Core.

Откройте в браузере URL-адрес, который был выведен в консоли (это должен быть адрес localhost:5000).

Сейчас структура вашего проекта должна соответствовать вот такой структуре.

Структура созданного проекта:

Чтобы упростить редактирование файлов в Visual Studio, создадим файл решения *.SIN и добавим в него все проекты.

.NET Standard

BCL — это набор базовых API, не зависящих от инфраструктур пользовательского интерфейса и моделей приложений. В него входят простые типы, файловый ввод-вывод, сетевые API, API сериализации, XML и другое.

Пример 3

Сравним его с файлом проекта консольного приложения hello.

Пример 4

Пример приложения с использованием PowerCollections:

Если вы запустите программу, то увидите следующее:

Компилятор выкинул warning но программа отработала!

Конечно, неустранимые предупреждения, которые выводятся при каждой сборке, очень раздражают (а точнее БЕСЯТ!). Поэтому после проверки приложения вы можете отключить предупреждение, связанное с конкретным пакетом. Наше приложение работает правильно (корректно выводит содержимое созданной коллекции типа Bag ), поэтому сейчас мы отключим это сообщение. Для этого изменим файл hello.csproj и добавим атрибут NoWarn в ссылку на пакет.

Если вы снова запустите приложение, предупреждения уже не будет. Однако, если вы установите другой пакет, в котором используется режим совместимости, появятся новые предупреждения. При необходимости их тоже можно будет отключить.

Заключение

Источник

Введение в ASP.NET Core

ASP.NET Core является кроссплатформенной, высокопроизводительной средой с открытым исходным кодом для создания современных облачных приложений, подключенных к Интернету. ASP.NET Core позволяет выполнять следующие задачи:

Преимущества, обеспечиваемые ASP.NET Core

Миллионы разработчиков использовали и продолжают использовать ASP.NET 4.x для создания веб-приложений. ASP.NET Core — это модификация ASP.NET 4.x с архитектурными изменениями, формирующими более рациональную и более модульную платформу.

ASP.NET Core предоставляет следующие преимущества:

Создание веб-API и пользовательского веб-интерфейса с помощью ASP.NET Core MVC

ASP.NET Core MVC предоставляет функции, которые позволяют создавать веб-интерфейсы API и веб-приложения.

Клиентская разработка

ASP.NET Core легко интегрируется с распространенными клиентскими платформами и библиотеками, в том числе Blazor, Angular, React и Bootstrap. Подробнее см. Введение в ASP.NET Core Blazor и связанные материалы о разработке на стороне клиента.

Целевые версии платформы ASP.NET Core

Рекомендуемая схема обучения

Для знакомства с разработкой приложений ASP.NET Core рекомендуется изучить следующую последовательность учебников.

Пройдите учебник по тому типу приложения, которое вы собираетесь разрабатывать или обслуживать.

Пройдите учебник, посвященный основам доступа к данным.

Ознакомьтесь с обзором основ ASP.NET Core, относящихся ко всем типам приложений.

Просмотрите содержание, чтобы найти другие интересующие вас темы.

†Доступен интерактивный учебник по веб-API. Локальная установка средств разработки не требуется. Код выполняется в Azure Cloud Shell в браузере, а для тестирования используется curl.

Справочное руководство по миграции приложений ASP.NET 4.x на ASP.NET Core см. в статье Миграция с ASP.NET на ASP.NET Core.

ASP.NET Core является кроссплатформенной, высокопроизводительной средой с открытым исходным кодом для создания современных облачных приложений, подключенных к Интернету. ASP.NET Core позволяет выполнять следующие задачи:

Преимущества, обеспечиваемые ASP.NET Core

Миллионы разработчиков использовали и продолжают использовать ASP.NET 4.x для создания веб-приложений. ASP.NET Core — это модификация ASP.NET 4.x с архитектурными изменениями, формирующими более рациональную и более модульную платформу.

ASP.NET Core предоставляет следующие преимущества:

Создание веб-API и пользовательского веб-интерфейса с помощью ASP.NET Core MVC

ASP.NET Core MVC предоставляет функции, которые позволяют создавать веб-интерфейсы API и веб-приложения.

Клиентская разработка

ASP.NET Core легко интегрируется с распространенными клиентскими платформами и библиотеками, в том числе Blazor, Angular, React и Bootstrap. Подробнее см. Введение в ASP.NET Core Blazor и связанные материалы о разработке на стороне клиента.

Рекомендуемая схема обучения

Для знакомства с разработкой приложений ASP.NET Core рекомендуется изучить следующую последовательность учебников и статей.

Пройдите учебник по тому типу приложения, которое вы собираетесь разрабатывать или обслуживать.

Пройдите учебник, посвященный основам доступа к данным.

Ознакомьтесь с обзором основ ASP.NET Core, относящихся ко всем типам приложений.

Просмотрите содержание, чтобы найти другие интересующие вас темы.

† Доступен новый учебник по веб-API с прохождением в браузере, не требующий установки локальной интегрированной среды разработки. Код выполняется в Azure Cloud Shell, а для тестирования используется curl.

Справочное руководство по миграции приложений ASP.NET на ASP.NET Core см. в статье Миграция с ASP.NET на ASP.NET Core.

Загрузка примера

Многие статьи и учебники содержат ссылки на примеры кода.

Директивы препроцессора в примере кода

Например, в следующем списке символов #define видно, что доступно четыре сценария (один сценарий на символ). В текущем примере конфигурации запускается сценарий TemplateCode :

Дополнительные сведения об использовании директив препроцессора C# для выборочной компиляции фрагментов кода см. в разделах #define (Справочник по C#) и #if (Справочник по C#).

Регионы в примере кода

Некоторые примеры приложений содержат фрагменты кода внутри директив C# #region и #endregion. Система сборки документации вставляет эти регионы в обработанные разделы документации.

Названия регионов обычно содержат слово «фрагмент». В следующем примере показан регион с именем snippet_WebHostDefaults :

На предыдущий фрагмент кода C# указывает ссылка в следующей строке в файле Markdown раздела:

Вы можете спокойно проигнорировать или удалить директивы #region и #endregion вокруг кода. Не изменяйте код внутри этих директив, если планируете запустить примеры сценариев, описанные в разделе. Вы можете изменить код, экспериментируя с другими сценариями.

Критические изменения и советы по безопасности

Критические изменения и рекомендации по безопасности отображаются в репозитории объявлений. Объявления можно ограничить определенной версией, выбрав фильтр меток.

Дальнейшие действия

Дополнительные сведения см. в следующих ресурсах:

Источник

.NET – набор вертикалей

Конечно, в самой идее предлагать специализированный набор возможностей, удовлетворяющих определенными потребностям, нет ничего плохого. Это становится проблемой, когда отсутствует системный подход и специализация происходит на каждом слое без учета того, что происходит в соответствующих слоях других вертикалей. Последствием таких решения является набор платформ, которые имеют ряд общих API только потому, что они когда-то начинались из единой базы кода. Со временем, это приводит к росту различий, если только не проводить явные (и дорогие) упражнения для достижения единообразия API.

В какой момент возникает проблема с фрагментацией? Если вы нацелены только на одну вертикаль, то в реальности никакой проблемы нет. Вам предоставлен набор API, оптимизированный именно для вашей вертикали. Проблема проявляет себя, как только вы хотите делать что-то горизонтальное, ориентированное на множество вертикалей. Вот теперь вы задаетесь вопросом о доступности различных API и думаете, как производить блоки кода, которые работали бы на разных целевых вертикалях.

Рождение переносимых библиотек классов (Portable Class Library, PCL)

Изначально не было никакого специального концепта для разделения кода между различными вертикалями. Не было переносимых библиотек классов или разделяемых проектов. Вам буквально было нужно создавать множество проектов, использовать ссылки на файлы и множество #if. Это делало задачу нацеливания кода на множество вертикалей действительно сложной.

К моменту выхода Windows 8 мы пришли к плану, как бороться с этой проблемой. Когда мы проектировали профиль Windows Store, мы ввели новую концепцию для лучшего моделирования подмножества: контракты.

Идея контрактов заключается в том, чтобы предоставить продуманный набор API, подходящих для задач декомпозиции кода. Контракты – это просто сборки, под которые вы можете компилировать свой код. В отличие от обычных сборок, сборки контрактов спроектированы именно под задачи декомпозиции. Мы четко прослеживаем зависимости между контрактами и пишем их так, чтобы они отвечали за что-то одно, а не были свалкой API. Контракты имеют независимую версионность и следуют соответствующим правилам, например, если добавляется новый API, то он будет доступен в сборке с новой версией.

Сегодня мы используем контракты для моделирования API во всех вертикалях. Вертикаль может просто взять и выбрать, какие контракты она будет поддерживать. Важным моментом является то, что вертикаль обязана поддерживать контракт целиком или не поддерживать вовсе. Другими словами, она не может включить в себя подмножество контракта.

Это позволяет говорить о различиях в API между вертикалями уже на уровне сборок в отличие от индивидуальных различиях в API, как это было раньше. Это позволяет нам реализовать механизм библиотек кода, которые нацелены на множество вертикалей. Такие библиотеки сегодня известны как переносимые библиотеки классов (portable class libraries).

Объединение формы API против объединения реализаций

Намного лучше унифицировать реализации: вместо того, чтобы только предоставлять хорошо декомпозированное описание, мы должные подготовить декомпозированную реализацию. Это позволит вертикалям просто использовать одну и ту же реализацию. Сближение вертикалей больше не будет требовать дополнительных действий; оно достигается просто за счет правильного конструирования решения. Конечно все равно будут случаи, в которых необходимы различные реализации. Хороший пример этого – это файловые операции, требующие использования разных технологий в зависимости от окружения. Однако, даже в этом случае намного проще попросить каждую команду, отвечающую за конкретные компонент, подумать, как из API будут работать в разных вертикалях, чем постфактум пытаться предоставить единый набор API поверх. Переносимость – это не есть что-то, что вы можете добавить после. К примеру, наш File API включает поддержку Windows Access Control Lists (ACL), которые не поддерживаются всем окружениями. При дизайне API нужно учитывать такие моменты и, в частности, предоставлять подобную функциональность в отдельных сборках, которые могут отсутствовать на платформах, не поддерживающих ACL.

Фреймворки для всей машины против локальных фреймворков для приложения

Это все очень редкие случаи, но, когда у вас пользовательская база в 1.8 миллиарда машин, быть совместимым с 99.9% по-прежнему означает, что 1.8 миллиона машин затронуто.

Интересно, что во многих случая исправить затронутые приложения требует довольно простых действий. Но проблема в том, что разработчик приложения не всегда доступен в момент поломки. Давайте рассмотрим конкретный пример.

Такой подход в общем-то почти полностью снимает все проблемы, мешающие вам обновиться до свежей версии. Ваши возможности перейти на новую версию ограничены только вашей возможностью выпустить новую версию вашего приложения. Это также означает, что вы контролируете, какая версия библиотеки используется конкретным приложением. Обновления производятся в контексте одного приложения, никак не затрагивая другие приложения на той же машине.

Это позволяет выпускать обновления в гораздо более гибкой манере. NuGet также предлагает возможность попробовать предварительные версии, что позволяет нам выпускать сборки без строгих обещаний относительно работы конктретных API. Такой подход позволяет нам поддерживать процесс, в котором мы предлагаем вам наш свежий взгляд на дизайн сборки – и, если вам не нравится, просто его изменить. Хороший пример это – это неизменяемые коллекции (immutable collections). Бета-период длился порядка 9 месяцев. Мы потратили много времени, пытаясь добиться правильного дизайна прежде, чем выпустить первую версию. Нет необходимости говорить, что финальная версия дизайна библиотеки, — благодаря вашим многочисленным отзывам, — намного лучше, чем начальная.

.NET Core – это модульная реализация, которая может использоваться широким набором вертикалей, начиная с дата-центров и заканчивая сенсорными устройствами, доступная с открытым исходным кодом, и поддерживаемая Microsoft на Windows, Linux и Mac OSX.

NuGet как первоклассный механизм доставки

Для слоя BCL у нас будет прямое соответствие между сборками и пакетами NuGet.

В дальнейшем NuGet-пакеты будут иметь те же имена, что и сборки. К примеру, неизменяемые коллекции перестанут распространяться под именем Microsoft.Bcl.Immutable и вместо этого будут в пакет, называющемся System.Collections.Immutable.

В дополнение, мы решили использовать семантический подход для версионности сборок. Номер версии NuGet-пакета будет согласован с версией сборки.

Согласованность именования и версионности между сборками и пакетами сильно облегчит их поиск. У вас не должно возникнуть вопроса, в каком пакете содержится System.Foo, Version=1.2.3.0 – он находится в пакете System.Foo с версией 1.2.3.

Готов для корпоративного использования

Основа для открытого кода и кросс-платформенности

Из прошлого опыта мы знаем, что успех открытого кода зависит от сообщества вокруг него. Ключевой аспект этого – это открытый и прозрачный процесс разработки, который позволит сообществу участвовать в ревью кода, знакомиться с документам по проектированию и вносить свои изменения в продукт.

Конечно, отдельные компоненты, например, файловая система, требуют отдельной реализации. Модель доставки через NuGet позволяет нам абстрагироваться от этих различий. Мы можем иметь единый NuGet-пакет, предоставляющий различные реализации для каждого из окружений. Однако важный момент тут как раз в том, что это внутренняя кухня реализации компонента. С точки зрения разработчика это единый API, который работает на разных платформах.

Наличие всех трех элементов позволяет нам добиться широкого спектра гибкости и зрелости решений:

Нам кажется, что мы нашли хороший баланс между тем, чтобы заложить основу для будущего, сохраняя при этом хорошую совместимость с существующими стеками. Давайте посмотрим детальнее на часть из этих платформ.

.NET Framework 4.6

Windows Store и Windows Phone

Более детально выбор между двумя подходами описан в статье «Sharing code across platforms».

Итоги

На нас лежит ответственность за продолжение выпуска критичных обновлений безопасности, не требующих работы со стороны разработчиков приложений, даже если затрагиваемые компоненты распространятся эксклюзивно как NuGet-пакеты.

А вот и другие наши статьи по схожей тематике:

Источник

.NET — это бесплатная платформа разработки с открытым исходным кодом для создания различных типов приложений, таких как следующие:

Для совместного использования функциональных возможностей различных приложений и типов приложений используются библиотеки классов.

Кроссплатформенные

Поддерживаемые архитектуры процессоров:

.NET позволяет использовать специальные возможности платформы, такие как API операционной системы. Примерами являются Windows Forms и WPF в Windows и собственные привязки к каждой мобильной платформе из Xamarin.

Открытый исходный код

Поддержка

Инструменты и производительность

.NET предоставляет возможность выбора языков, интегрированных сред разработки (IDE) и других средств.

Языки программирования

C# (произносится как «си шарп») — современный объектно-ориентированный и типобезопасный язык программирования. C# относится к широко известному семейству языков C, и покажется хорошо знакомым любому, кто работал с C, C++, Java или JavaScript.

Язык F# поддерживает функциональные, объектно-ориентированные и императивные модели программирования.

Интегрированные среды разработки

Онлайн-среда Visual Studio Code, которая в настоящее время доступна в виде бета-версии.

Пакет SDK и среды выполнения

Загружаемый пакет SDK содержит следующие компоненты.

Загружаемая среда выполнения содержит следующие компоненты.

Дополнительные сведения см. в следующих ресурсах:

Система проектов и MSBuild

И вот один для веб-приложения:

NuGet

Дополнительные сведения см. в документации NuGet.

.NET Interactive — это группа средств и интерфейсов командной строки, которые позволяют пользователям создавать интерактивные возможности в веб-приложениях, разметке и записных книжках.

Дополнительные сведения см. в следующих ресурсах:

Модели выполнения.

.NET CLR — это кроссплатформенная среда выполнения, которая включает поддержку Windows, macOS и Linux. Среда CLR обрабатывает выделение памяти и управление ей. Среда CLR также является виртуальной машиной, которая не только выполняет приложения, но и создает, а также компилирует код с помощью JIT-компилятора.

Для получения дополнительной информации см. Common Language Runtime.

JIT-компилятор и промежуточный язык

Так как JIT-компиляция происходит во время выполнения приложения, время компиляции является частью времени выполнения. Таким образом, JIT-компиляторы должны поддерживать баланс между временем оптимизации кода и экономии, к которой может привести результирующий код. Но JIT-компилятор знает фактическое оборудование и может освободить разработчиков от поставки различных реализаций для различных платформ.

Компилятор AOT

Автоматическое управление памятью

Сборщик мусора (GC) управляет выделением и освобождением памяти для приложений. Каждый раз, когда код создает новый объект, среда CLR выделяет память для объекта из управляемой кучи. Пока в управляемой куче есть доступное адресное пространство, среда выполнения продолжает выделять пространство для новых объектов. Когда остается недостаточное свободное пространство адресов, сборщик мусора проверяет наличие объектов в управляемой куче, которые больше не используются приложением. Затем эта память освобождается.

GC — это одна из служб CLR, которая помогает обеспечить безопасность памяти. Программа является безопасной по памяти, если она обращается только к выделенной памяти. Например, среда выполнения гарантирует, что приложение не обращается к невыделенной памяти за пределами границ массива.

Дополнительные сведения о сборке мусора см. в статьях Автоматическое управление памятью и Основы сборки мусора.

Работа с неуправляемыми ресурсами

Дополнительные сведения см. в разделе Очистка неуправляемых ресурсов.

Модели развертывания

Можно установить несколько версий среды выполнения параллельно, чтобы запускать зависящие от платформы приложения, предназначенные для разных версий среды выполнения. Дополнительные сведения см. в разделе Целевые платформы.

Исполняемые файлы создаются для конкретных целевых платформ, которые указываются с помощью идентификатора среды выполнения (RID).

Библиотеки среды выполнения.

.NET имеет обширный стандартный набор библиотек классов, известный как библиотеки среды выполнения, библиотеки платформы или библиотеки базовых классов (BCL). Эти библиотеки предоставляют реализации для многих общих и зависящих от рабочей нагрузки типов, а также функциональные возможности.

Расширения библиотек среды выполнения

Библиотеки для некоторых часто используемых функциональных возможностей приложения не включены в библиотеки среды выполнения, но доступны в пакетах NuGet, как показано ниже.

Доступ к данным

.NET предоставляет объектно-реляционный модуль сопоставления (ORM) и способ написания SQL-запросов в коде.

Entity Framework Core

LINQ позволяет писать декларативный код для работы с данными. Данные могут быть представлены разными формами (например, объектами в памяти, содержимым базы данных SQL или XML-документом), но обычно создаваемый код LINQ не отличается для каждого из источников данных.

Уточнение терминологии

Среда выполнения

платформа

Пакет SDK

platform

Сложные сценарии

Взаимодействие на уровне машинного кода

Основным способом осуществления взаимодействия с собственными API является «вызов неуправляемого кода» или сокращенно P/Invoke. P/Invoke поддерживается на платформах Linux и Windows. Способ, который подходит только для Windows, называется «COM-взаимодействием» и используется для работы с COM-компонентами в управляемом коде. Он основан на инфраструктуре P/Invoke, но работает иначе.

Небезопасный код

Дополнительные сведения см. в разделе Небезопасный код и указатели.

Источник