В преддверии старта курса C# ASP.NET Core разработчик подготовили традиционный перевод полезного материала.

Также приглашаем на открытый вебинар по теме Отличия структурных шаблонов проектирования на примерах. На вебинаре участники вместе с экспертом рассмотрят три структурных шаблона проектирования: Заместитель, Адаптер и Декоратор; а также напишут несколько простых программ и проведут их рефакторинг.

Введение

Program.cs это место, с которого начинается приложение. Файл Program.cs в ASP.NET Core работает так же, как файл Program.cs в традиционном консольном приложении .NET Framework. Файл Program.cs является точкой входа в приложение и отвечает за регистрацию и заполнение Startup.cs, IISIntegration и создания хоста с помощью инстанса IWebHostBuilder, метода Main.

Global.asax больше не входит в состав приложения ASP.NET Core. В ASP.NET Core заменой файла Global.asax является файл Startup.cs.

Файл Startup.cs это также точка входа, и он будет вызываться после выполнения файла Program.cs на уровне приложения. Он обрабатывает конвейер запросов. Класс Startup запускается в момент запуска приложения.

Описание

Что такое Program.cs?

Program.cs это место, с которого начинается приложение. Файл класса Program.cs является точкой входа в наше приложение и создает инстанс IWebHost, на котором размещается веб-приложение.

public class Program {      public static void Main(string[] args) {          BuildWebHost(args).Run();      }      public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args).UseStartup < startup > ().Build();  }  

WebHost используется для создания инстансов IWebHost, IWebHostBuilder и IWebHostBuilder, которые имеют предварительно настроенные параметры. Метод CreateDefaultBuilder() создает новый инстанс WebHostBuilder.

Метод UseStartup() определяет класс Startup, который будет использоваться веб-хостом. Мы также можем указать наш собственный пользовательский класс вместо Startup.

Метод Build() возвращает экземпляр IWebHost, а Run() запускает веб-приложение до его полной остановки.

Program.cs в ASP.NET Core упрощает настройку веб-хоста.

public static IWebHostBuilder CreateDefaultBuilder(string[] args) {      var builder = new WebHostBuilder().UseKestrel().UseContentRoot(Directory.GetCurrentDirectory()).ConfigureAppConfiguration((hostingContext, config) => {          /* setup config */ }).ConfigureLogging((hostingContext, logging) => {          /* setup logging */ }).UseIISIntegration()      return builder;  }

Метод UseKestrel() является расширением, которое определяет Kestrel как внутренний веб-сервер. Kestrel это кроссплатформенный веб-сервер для ASP.NET Core с открытым исходным кодом. Приложение работает с модулем Asp.Net Core, и необходимо включить интеграцию IIS (UseIISIntegration()), которая настраивает базовый адрес и порт приложения.

Он также настраивает UseIISIntegration(), UseContentRoot(), UseEnvironment(Development), UseStartup() и другие доступные конфигурации, например Appsetting.json и Environment Variable. UseContentRoot используется для обозначения текущего пути к каталогу.

Мы также можем зарегистрировать логирование и установить минимальный loglevel, как показано ниже. Это также переопределитloglevel, настроенный в файле appsetting.json.

.ConfigureLogging(logging => { logging.SetMinimumLevel(LogLevel.Warning); }) 

Таким же образом мы можем контролировать размер тела нашего запроса и ответа, включив эту опцию файле program.cs, как показано ниже.

.ConfigureKestrel((context, options) => { options.Limits.MaxRequestBodySize = 20000000; });  

ASP.net Core является кроссплатформенным и имеет открытый исходный код, а также его можно размещать на любом сервере (а не только на IIS, внешнем веб-сервере), таком как IIS, Apache, Nginx и т. д.

Что такое файл Startup?

Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal. В одном приложении допускается использование нескольких классов Startup. ASP.NET Core выберет соответствующий класс в зависимости от среды.

Если существует класс Startup{EnvironmentName}, этот класс будет вызываться для этого EnvironmentName или будет выполнен файл Startup для конкретной среды в целом (Environment Specific), чтобы избежать частых изменений кода/настроек/конфигурации в зависимости от среды.

ASP.NET Core поддерживает несколько переменных среды, таких как Development, Production и Staging. Он считывает переменную среды ASPNETCORE_ENVIRONMENT при запуске приложения и сохраняет значение в интерфейсе среды хоста (into Hosting Environment interface).

Обязательно ли этот класс должен называться startup.cs? Нет, имя класса не обязательно должно быть Startup.

Мы можем определить два метода в Startup файле, например ConfigureServices и Configure, вместе с конструктором.

Пример Startup файла

public class Startup {      // Use this method to add services to the container.      public void ConfigureServices(IServiceCollection services) {          ...      }      // Use this method to configure the HTTP request pipeline.      public void Configure(IApplicationBuilder app) {          ...      }  }  

Метод ConfigureServices

Это опциональный метод в классе Startup, который используется для настройки сервисов для приложения. Когда в приложение поступает какой-либо запрос, сначала вызывается метод ConfigureService.

Метод ConfigureServices включает параметр IServiceCollection для регистрации сервисов. Этот метод должен быть объявлен с модификатором доступа public, чтобы среда могла читать контент из метаданных.

public void ConfigureServices(IServiceCollection services)  {     services.AddMvc();  }  

Метод Configure

Метод Configure используется для указания того, как приложение будет отвечать на каждый HTTP-запрос. Этот метод в основном используется для регистрации промежуточного программного обеспечения (middleware) в HTTP-конвейере. Этот метод принимает параметр IApplicationBuilder вместе с некоторыми другими сервисами, такими как IHostingEnvironment и ILoggerFactory. Как только мы добавим какой-либо сервис в метод ConfigureService, он будет доступен для использования в методе Configure.

public void Configure(IApplicationBuilder app)  {     app.UseMvc();  }

В приведенном выше примере показано, как включить функцию MVC в нашем фреймворке. Нам нужно зарегистрировать UseMvc() в Configure и сервис AddMvc() в ConfigureServices. UseMvc является промежуточным программным обеспечением. Промежуточное программное обеспечение (Middleware) это новая концепция, представленная в Asp.net Core. Для вас доступно множество встроенных промежуточных программ, некоторые из которых указаны ниже.

app.UseHttpsRedirection();  app.UseStaticFiles();  app.UseRouting();  app.UseAuthorization();  UseCookiePolicy();  UseSession(); 

Промежуточное программное обеспечение можно настроить в http-конвейере с помощью команд Use, Run и Map.

Run

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

Use

Это передаст следующему (параметр next) делегату, так что HTTP-запрос будет передан следующему промежуточному программному обеспечению после выполнения текущего, если следующий делегат есть.

Map

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

app.Map("/MyDelegate", MyDelegate);

Чтобы получить более подробную информацию о промежуточном программном обеспечении, переходите сюда

ASP.net Core имеет встроенную поддержку внедрения зависимостей (Dependency Injection). Мы можем настроить сервисы для контейнера внедрения зависимостей, используя этот метод. Следующие способы конфигурационные методы в Startup классе.

AddTransient

Transient (временные) объекты всегда разные; каждому контроллеру и сервису предоставляется новый инстанс.

Scoped

Scoped используются одни и те же объекты в пределах одного запроса, но разные в разных запросах.

Singleton

Singleton объекты одни и те же для каждого объекта и каждого запроса.

Можем ли мы удалить startup.cs и объединить все в один класс с Program.cs?

Ответ: Да, мы можем объединить все классы запуска в один файл.

Заключение

Вы получили базовое понимание того, почему файлы program.cs и startup.cs важны для нашего приложения Asp.net Core и как их можно настроить. Мы также немного познакомились с переменной среды (Environment Variable), внедрение зависимостей, промежуточным программным обеспечением и как его настроить. Кроме того, мы увидели, как можно настроить UseIIsintegration() и UseKestrel().

Узнать подробнее о курсе C# ASP.NET Core разработчик.

Смотреть открытый вебинар по теме Отличия структурных шаблонов проектирования на примерах.

Новая версия .NET, 6 Preview 1, уже доступна и готова к вашей оценке. Это первая предварительная версия .NET 6, следующего крупного обновления платформы .NET. Ожидается, что .NET 6 поступит в полноценный доступ в ноябре этого года и будет выпуском с долгосрочной поддержкой (LTS).

Если вы работаете с Windows и используете Visual Studio, мы рекомендуем установить последнюю предварительную версию Visual Studio 2019 16.9. Если вы используете macOS, мы рекомендуем установить последнюю предварительную версию Visual Studio 2019 для Mac 8.9.

Основная работа, запланированная с ASP.NET Core в .NET 6

.NET 6 использует открытый процесс планирования, поэтому вы можете изучить все основные темы, запланированные для этого релиза, на Blazor-веб-сайте themesof.net. В дополнение к этим верхнеуровневым темам мы собираемся также предоставить множество улучшений, ориентированных на пользователей. Вы можете найти список основных задач, запланированных для ASP.NET Core в .NET 6, в нашем выпуске дорожной карты. Вот некоторые из основных функций ASP.NET Core, запланированных для выпуска .NET 6:

• Горячая перезагрузка: быстро обновляйте пользовательский интерфейс и код для работающих приложений без потери состояния приложения для более быстрой и продуктивной разработки.

• Микро API: Упростите создание конечных точек API с гораздо меньшим количеством кода и церемоний.

• Публикация в виде одного файла: создавайте небольшие автономные высокопроизводительные приложения и службы.

• Компиляция WebAssembly с опережением времени (AoT): компилируйте код .NET в приложениях Blazor WebAssembly непосредственно в WebAssembly при публикации для значительного повышения производительности во время выполнения.

• Обновленная поддержка одностраничных приложений (SPA). Обновите интеграцию SPA в ASP.NET Core для бесперебойной работы с последними современными интерфейсными платформами JavaScript.

• Гибридные настольные приложения Blazor: объедините лучшее из пользовательского интерфейса многоплатформенных приложений Blazor и .NET для создания кроссплатформенных гибридных настольных приложений.

• HTTP/3: добавьте поддержку HTTP/3 и QUIC на поддерживаемые серверы ASP.NET Core.

Мы приветствуем отзывы и участие в процессе планирования и создания на GitHub.

Что нового в ASP.NET Core в .NET 6 Preview 1?

• Поддержка IAsyncDisposableв MVC

• DynamicComponent

• InputElementReferenceразделен на релевантные компоненты

• dotnet watchтеперь являетсяdotnet watch runпо дефолту

• Nullable reference type annotations

Начало работы

Чтобы начать работу с ASP.NET Core в .NET 6 Preview 1, установите .NET 6 SDK.

Обновление существующего проекта

Чтобы обновить существующее приложение ASP.NET Core с .NET 5 до .NET 6 Preview 1:

• Обновите целевую платформу для вашего приложения, доnet6.0.

• Обновите все ссылки на пакеты Microsoft.AspNetCore.* до6.0.0-preview.1.*.

• Обновите все ссылки на пакеты Microsoft.Extensions.* до6.0.0-preview.1.*.

См. полный список критических изменений в ASP.NET Core для .NET 6 здесь.

DynamicComponent

DynamicComponent - это новый встроенный компонент Blazor, который можно использовать для динамической визуализации компонента, указанного по типу.

<DynamicComponent Type="@someType" />

Параметры могут быть переданы визуализируемому компоненту с помощью dictionary:

<DynamicComponent Type="@someType" Parameters="@myDictionaryOfParameters" />@code {    Type someType = ...    IDictionary<string, object> myDictionaryOfParameters = ...}

InputElementReferenceразделен на релевантные компоненты

Соответствующие встроенные компоненты Blazor ввода теперь предоставляют удобную ссылку ElementReference для базового ввода, что упрощает распространенные сценарии, такие как установка фокуса пользовательского интерфейса на вводе. Затронутые компоненты: InputCheckbox, InputDate, InputFile, InputNumber, InputSelect, InputText и InputTextArea.

dotnet watchтеперь являетсяdotnet watch runпо дефолту

Запуск dotnet watch теперь будет запускать dotnet watch run по умолчанию, экономя драгоценное время ввода.

Nullable Reference Type Annotations

Мы применяем аннотации обнуляемости к частям ASP.NET Core. Значительное количество новых API было аннотировано в .NET 6 Preview 1.

Используя новую функцию C# 8, ASP.NET Core может обеспечить дополнительную безопасность во время компиляции при обработке ссылочных типов, например защиту от исключений нулевых ссылок. Проекты, которые выбрали использование аннотаций, допускающих значение NULL, могут видеть новые предупреждения во время сборки от API-интерфейсов ASP.NET Core.

Чтобы включить ссылочные типы, допускающие значение NULL, вы можете добавить в файл проекта следующее свойство:

<PropertyGroup>    <Nullable>enable</Nullable></PropertyGroup>

Подробности читайте здесь.

Привет, хабр! Прямо сейчас OTUS открывает набор на новый поток курса "C# ASP.NET Core разработчик". В связи с этим традиционно делимся с вами полезным переводом и приглашаем записаться на день открытых дверей, в рамках которого можно будет подробно узнать о курсе, а также задать эксперту интересующие вас вопросы.

Это первая статья из серии, посвященной локализации в ASP.NET Core Razor Pages приложениях. В этой статье мы рассмотрим конфигурацию, необходимую для подготовки сайта к локализации контента, или другими словами, для глобализации сайта. В следующих статьях я расскажу о создании локализованного контента и о том, как преподносить его конечному пользователю.

Глобализация в ASP.NET Core

Глобализация - это подготовка приложения к поддержке различных языков в зависимости от предпочтений пользователя. Локализация - это процесс адаптации контента сайта под разные страны, регионы или культуры. Отправной точкой в глобализации веб-приложения является способность определять язык или культуру для каждого запроса. Далее нам потребуется механизм для выбора контента на основе культуры текущего запроса. В этой статье мы рассмотрим роль, которую играет класс CultureInfo в локализации, и то, как можно реализовать компонент представления, чтобы пользователи могли выбирать для запросов предпочтительную для них культуру.

Приведенные ниже шаги добавляют базовую локализацию к Razor Pages приложению, которое создается из стандартного шаблона веб-приложения ASP.NET Core 3.0 без настроенной аутентификации. Я назвал свое приложение Localisation. Свое вы можете назвать как вам угодно, но в таком случае не забудьте про пространства имен, если будете копировать код из этой статьи.

1. Начните с открытия файла Startup.cs и добавления туда следующих using директив:

using System.Globalization;using Microsoft.AspNetCore.Localization;using Microsoft.Extensions.Options;

2. Локализация - это дополнительная фича. По умолчанию она не включена. Измените метод ConfigureServices, включив AddLocalization, что сделает различные вспомогательные сервисы локализации доступными для системы инжекции зависимостей. Затем добавьте следующий код для конфигурации RequestLocalizationOptions в приложении.

services.Configure<RequestLocalizationOptions>(options =>{   var supportedCultures = new[]    {        new CultureInfo("en"),        new CultureInfo("de"),        new CultureInfo("fr"),        new CultureInfo("es"),        new CultureInfo("ru"),        new CultureInfo("ja"),        new CultureInfo("ar"),        new CultureInfo("zh"),        new CultureInfo("en-GB")    };    options.DefaultRequestCulture = new RequestCulture("en-GB");    options.SupportedCultures = supportedCultures;    options.SupportedUICultures = supportedCultures;});

Вам необходимо указать языки или культуры, которые вы планируете поддерживать в своем приложении. Культуры представлены в .NET классом CultureInfo, который содержит информацию о форматировании чисел и дат, календарях, системах письма, порядках сортировки и других вопросах, зависящих от местности проживания конечного пользователя. Перегрузка конструктора класса CultureInfo, используемого здесь, принимает строку, представляющую имя языка и региональных параметров (культуры). Допустимые значения - это коды ISO 639-1, которые представляют язык (например, en для английского языка), с необязательным кодом субкультуры ISO 3166, который представляет страну или диалект (например, en-GB для Великобритании или en-ZA для Южной Африки). В приведенном выше примере поддерживается несколько языков, включая одну субкультуру - британский английский, который был установлен в качестве культуры по умолчанию.

3. Теперь, когда RequestLocalizationOptions настроены, их можно применить к промежуточной прослойке локализации запросов, которую необходимо добавить в метод Configure после app.UseRouting():

app.UseHttpsRedirection();app.UseStaticFiles();app.UseRouting();var localizationOptions = app.ApplicationServices.GetService<IOptions<RequestLocalizationOptions>>().Value;app.UseRequestLocalization(localizationOptions);

Установка культуры запроса

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

• QueryStringRequestCultureProvider, который получает культуру из строки запроса

• CookieRequestCultureProvider, который получает культуру из файла cookie

• AcceptHeadersRequestCultureProvider, который получает культуру из хедераAccept-Language браузера

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

1. Первый шаг - создать папку с именем Models и добавить в нее файл класса с именем CultureSwitcherModel.cs.

using System.Collections.Generic;using System.Globalization; namespace Localisation.Models{    public class CultureSwitcherModel    {        public CultureInfo CurrentUICulture { get; set; }        public List<CultureInfo> SupportedCultures { get; set; }    }}

2. Добавьте в проект папку с именем ViewComponents и в нее добавьте новый файл класса C# с именем CultureSwitcherViewcomponent.cs. Затем замените содержимое на следующий код:

using Localisation.Models;using Microsoft.AspNetCore.Builder;using Microsoft.AspNetCore.Localization;using Microsoft.AspNetCore.Mvc;using Microsoft.Extensions.Options;using System.Linq; namespace Localisation.ViewComponents{    public class CultureSwitcherViewComponent : ViewComponent    {        private readonly IOptions<RequestLocalizationOptions> localizationOptions;        public CultureSwitcherViewComponent(IOptions<RequestLocalizationOptions> localizationOptions) =>            this.localizationOptions = localizationOptions;         public IViewComponentResult Invoke()        {            var cultureFeature = HttpContext.Features.Get<IRequestCultureFeature>();            var model = new CultureSwitcherModel            {                SupportedCultures = localizationOptions.Value.SupportedUICultures.ToList(),                CurrentUICulture = cultureFeature.RequestCulture.UICulture            };            return View(model);        }    }}

3. Добавьте новую папку в папку Pages и назовите ее Components. Внутри добавьте еще одну папку с именем CultureSwitcher. Затем добавьте Razor View в default.cshtml и замените существующее содержимое следующим:

@model CultureSwitcherModel <div>    <form id="culture-switcher">        <select name="culture" id="culture-options">            <option></option>            @foreach (var culture in Model.SupportedCultures)            {                <option value="@culture.Name" selected="@(Model.CurrentUICulture.Name == culture.Name)">@culture.DisplayName</option>            }        </select>    </form></div>  <script>    document.getElementById("culture-options").addEventListener("change", () => {        document.getElementById("culture-switcher").submit();    });</script>

Компонент представления - это простой select элемент, заполненный поддерживаемыми культурами, которые были настроены в Startup. Представление, в котором он находится, использует дефолтный get метод, что означает, что отправленное значение появится в строке запроса с именем culture. QueryStringRequestCultureProvider предназначен для поиска элемента в строке запроса по ключа culture (и/или ui-culture).

CurrentCulture для запроса определяет местное форматирование которое будет использоваться для таких вещей как даты и числа. CurrentUICulture используется, чтобы выбрать правильный ресурс, содержащий переведенные строки. В следующей статье этой серии я рассмотрю, как использовать ресурсные файлы для локализации статического контента. Для CurrentCulture и CurrentUICulture можно установить разные значения, но чаще имеет смысл, чтобы оба эти значения совпадали. Если установлено только одно из них (например, через одно значение строки запроса), то значение присваивается обоим свойствам.

4. На этом этапе у вас, вероятно, у вас появилось несколько красных волнистых линий в только что созданном представлении - откройте файл _ViewImports.cshtml и добавьте вторую и третью директивы using, приведенные ниже, вместе с последней строкой, которая позволяет вам использовать tag-хелпер для рендеринга компонент представления:

@using Localisation@using Localisation.Models@using System.Globalization@namespace Localisation.Pages@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers@addTagHelper *, Localisation

5. Включите компонент переключателя культуры на страницу макета, используя подход с tag-хелпером, как показано здесь в последней строке.

<div class="navbar-collapse collapse d-sm-inline-flex flex-sm-row-reverse">    <ul class="navbar-nav flex-grow-1">        <li class="nav-item">            <a class="nav-link text-dark" asp-area="" asp-page="/Index">Home</a>        </li>        <li class="nav-item">            <a class="nav-link text-dark" asp-area="" asp-page="/Privacy">Privacy</a>        </li>    </ul></div><vc:culture-switcher/>

6. Измените Index.cshtml, включив код в блок кода и HTML-код для таблицы, которая отображает различные биты данных:

@page@using Microsoft.AspNetCore.Localization@model IndexModel@{    ViewData["Title"] = "Home page";    var requestCultureFeature = HttpContext.Features.Get<IRequestCultureFeature>();    var requestCulture = requestCultureFeature.RequestCulture;} <div class="text-center">    <h1 class="display-4">Welcome</h1>    <p>Learn about <a href="http://personeltest.ru/aways/docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>     <table class="table culture-table">        <tr>            <td style="width:50%;">Culture</td>            <td>@requestCulture.Culture.DisplayName {@requestCulture.Culture.Name}</td>        </tr>        <tr>            <td>UI Culture</td>            <td>@requestCulture.UICulture.Name</td>        </tr>        <tr>            <td>UICulture Parent</td>            <td>@requestCulture.UICulture.Parent</td>        </tr>        <tr>            <td>Date</td>            <td>@DateTime.Now.ToLongDateString()</td>        </tr>        <tr>            <td>Currency</td>            <td>                @(12345.00.ToString("c"))            </td>        </tr>        <tr>            <td>Number</td>            <td>                @(123.45m.ToString("F2"))            </td>        </tr>    </table></div>

При первом запуске приложения культура для запроса задается AcceptHeadersCultureRequestProvider. Когда вы используете раскрывающийся список для выбора разных культур, культура задается QueryStringCultureRequestProvider. Попробуйте добавить ключ ui-culture в строку запроса с другим значением ключа culture (например, https://localhost:xxxxx/?culture=es&ui-culture=de), чтобы посмотреть, что произойдет.

Резюме

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

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

Подробнее о курсе.

Читать ещё:

• Сжатие ответов в GRPC для ASP.NET CORE 3.0

Введение

Всем привет, в данной статье будет рассказано, как с использованием технологии C# ASP.NET Core написать простое Rest Api. Сделать Unit-тесты на слои приложений. Отправлять Json ответы. Также покажу, как выложить данное приложение в Docker.

В данной статье не будет описано, как делать клиентскую (далее Front) часть приложения. Здесь я покажу только серверную (далее Back).

Что используем?

Писать код я буду в Visual Studio 2019.

Для реализации приложения, я буду использовать такие библиотеки NuGet:

1. Microsoft.EntityFrameworkCore

2. Microsoft.EntityFrameworkCore.SqlServer

3. Microsoft.EntityFrameworkCore.Tools

Для тестов вот эти библиотеки:

1. Microsoft.NET.Test.Sdk

2. Microsoft.NETCore.App

3. Moq

4. xunit

5. xunit.runner.visualstudio

Для установки пакетов нужно зайти в обозреватель пакетов NuGet, сделать это можно, нажав ПКМ по проекту, и выбрав там пункт управление пакетам NuGet

Что программировать?

Для примера я возьму сильно упрощенную модель сервиса по ремонту автомобилей. В моей модели будут работники, которые будут заниматься ремонтом, автомобили, поступающие на ремонт, и документация по ремонту, которая будет отсылаться в ответе.

Настройка Базы Данных

Для настройки базы данных нужен класс ApplicationContext (реализация будет далее) и строка подключения, которая храниться в файле appsettings.json. В этом классе будут прописаны все зависимости для генерации миграций. Строка подключения нужна для того, чтобы приложение знало в какую БД ей обращаться и с какими параметрами.

Чтобы добавить строку подключения, достаточно зайти в файл appsettings.json и прописать следующие строки:

"ConnectionStrings": { "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=testdb;Trusted_Connection=True;" },

Описание слоев приложения

Модели

В слое моделей будут находиться сущности, которые с помощью Entity Framework будут преобразованы в таблицы в базе данных.

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

Первая модель, которая понадобиться для описания сервиса по ремонту - модель сотрудника. Что она будет из себя представлять?

• Уникальный идентификатор сотрудника

• Имя сотрудника

• Должность сотрудника

• Номер телефона для связи с сотрудником

Следующая модель для описания сервиса - автомобили, которые будут поступать на ремонт.

• Уникальный идентификатор автомобиля

• Название автомобиля

• Номер автомобиля

И последняя модель, которую мы уже будем отсылать - документ (выписка) по ремонту.

• Уникальный идентификатор документа

• Сотрудник, который обслуживал автомобиль

• Автомобиль, который был на ремонте

Чтобы модели попали в базу данных, необходимо создать миграцию. Миграция - описание того, как и что будет записано в базу данных. С помощью Entity Framework миграции можно генерировать автоматически. Для этого в пакетном менеджере надо прописать команду "Add-Migration". После этого Entity Framework сгенерирует миграцию по вашим моделям, которые указаны в классе DbContext. Чтобы применить миграцию, используем команду "Update-Database", после этого ваши данные попадут в базу данных (как это применять будет описано далее).

Контроллеры

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

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

new JsonResult(Ваш объект)

В данном примере, я покажу как сделать методы для GET, POST, PUT и DELETE запросов. В GET-запросе я буду выбирать все существующие документы и передавать их на Front, а в POST-запросе я буду вызывать сервис по ремонту автомобиля и возвращать выписку по ремонту, PUT будет отвечать за обновление существующего документа и DELETE за удаление документа.

DAO (Репозитории)

Репозитории нужны как посредники для обеспечения работы с БД, чтобы исключить прямое взаимодействие человека с данными. Это нужно для того, чтобы сокрыть логику работы автоматизировать многие моменты работы с БД, а также для безопасной работы с данными.

В своем приложении я сделал репозиторий, который может принимать любую модель, и выполнять такие действия как get, get all, update, create, delete.

Сервисы

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

В качестве примера сервиса, я сделал класс, всего с одним методом Work. Этот метод имитирует работу моего сервиса по починке машин. В этом методе нанимается рабочий, заводится автомобиль и заполняется документ о его починке.

Реализация

Теперь, когда описано что и как будет устроено в приложении можно приступить и к реализации.

Создание проекта

При создании нового проекта, я выбрал веб-приложение ASP.NET Core, далее прописал его название (RestApi) и выбрал папку, где оно будет храниться. На экране выбора шаблона выбрал API.

Далее приступим к самому приложению.

Структура

Я разделил все приложение по папкам (также Unit-тесты в отдельном проекте) и получил вот такую структуру мое приложения:

Модели

Для реализации моделей я сделал абстрактный класс BaseModel. Он понадобиться в будущем для корректного наследования, а также в нем прописан Id каждой, модели (это помогает не дублировать код):

 public abstract class BaseModel { public Guid Id { get; set; } }

Далее вышеописанные модели:

 public class Car : BaseModel { public string Name { get; set; } public string Number { get; set; } }

 public class Document : BaseModel { public Guid CarId { get; set; } public Guid WorkerId { get; set; } public virtual Car Car { get; set; } public virtual Worker Worker { get; set; } }

 public class Worker : BaseModel { public string Name { get; set; } public string Position { get; set; } public string Telephone { get; set; } }

Репозиторий

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

Интерфейс:

public interface IBaseRepository<TDbModel> where TDbModel : BaseModel    {        public List<TDbModel> GetAll();        public TDbModel Get(Guid id);        public TDbModel Create(TDbModel model);        public TDbModel Update(TDbModel model);        public void Delete(Guid id);    }

Реализация:

    public class BaseRepository<TDbModel> : IBaseRepository<TDbModel> where TDbModel : BaseModel    {        private ApplicationContext Context { get; set; }        public BaseRepository(ApplicationContext context)        {            Context = context;        }        public TDbModel Create(TDbModel model)        {            Context.Set<TDbModel>().Add(model);            Context.SaveChanges();            return model;        }        public void Delete(Guid id)        {            var toDelete = Context.Set<TDbModel>().FirstOrDefault(m => m.Id == id);            Context.Set<TDbModel>().Remove(toDelete);            Context.SaveChanges();        }        public List<TDbModel> GetAll()        {            return Context.Set<TDbModel>().ToList();        }        public TDbModel Update(TDbModel model)        {            var toUpdate = Context.Set<TDbModel>().FirstOrDefault(m => m.Id == model.Id);            if (toUpdate != null)            {                toUpdate = model;            }            Context.Update(toUpdate);            Context.SaveChanges();            return toUpdate;        }        public TDbModel Get(Guid id)        {            return Context.Set<TDbModel>().FirstOrDefault(m => m.Id == id);        }    }

Сервис

Сервис также как и репозиторий имеет интерфейс и его реализацию.

Интерфейс:

public interface IRepairService    {        public void Work();    }

Реализация:

public class RepairService : IRepairService    {        private IBaseRepository<Document> Documents { get; set; }        private IBaseRepository<Car> Cars { get; set; }        private IBaseRepository<Worker> Workers { get; set; }        public void Work()        {            var rand = new Random();            var carId = Guid.NewGuid();            var workerId = Guid.NewGuid();            Cars.Create(new Car            {                Id = carId,                Name = String.Format($"Car{rand.Next()}"),                Number = String.Format($"{rand.Next()}")            });            Workers.Create(new Worker            {                Id = workerId,                Name = String.Format($"Worker{rand.Next()}"),                Position = String.Format($"Position{rand.Next()}"),                Telephone = String.Format($"8916{rand.Next()}{rand.Next()}{rand.Next()}{rand.Next()}{rand.Next()}{rand.Next()}{rand.Next()}")            });            var car = Cars.Get(carId);            var worker = Workers.Get(workerId);            Documents.Create(new Document {                CarId = car.Id,                WorkerId = worker.Id,                Car = car,                Worker = worker            });        }    }

Контроллер

У меня в приложении всего один контроллер, но по его шаблону можно сделать сколько угодно контроллеров. Когда приложение запущено, для того чтобы обратиться к методу контроллера с Front части приложения, достаточно передать запрос, который выглядит примерно вот так:

ДоменноеИмя/НазваниеКонтроллера/НазваниеМетода?Параметры(если есть)

Пути гибко настраиваются с помощью специальных атрибутов (о них не в этой статье).

Мой MainController:

[ApiController]    [Route("[controller]")]    public class MainController : ControllerBase    {        private IRepairService RepairService { get; set; }        private IBaseRepository<Document> Documents { get; set; }        public MainController(IRepairService repairService, IBaseRepository<Document> document )        {            RepairService = repairService;            Documents = document;        }        [HttpGet]        public JsonResult Get()        {            return new JsonResult(Documents.GetAll());        }        [HttpPost]        public JsonResult Post()        {            RepairService.Work();            return new JsonResult("Work was successfully done");        }        [HttpPut]        public JsonResult Put(Document doc)        {            bool success = true;            var document = Documents.Get(doc.Id);            try            {                if (document != null)                {                    document = Documents.Update(doc);                }                else                {                    success = false;                }            }            catch (Exception)            {                success = false;            }            return success ? new JsonResult($"Update successful {document.Id}") : new JsonResult("Update was not successful");        }        [HttpDelete]        public JsonResult Delete(Guid id)        {            bool success = true;            var document = Documents.Get(id);            try            {                if (document != null)                {                    Documents.Delete(document.Id);                }                else                {                    success = false;                }            }            catch (Exception)            {                success = false;            }            return success ? new JsonResult("Delete successful") : new JsonResult("Delete was not successful");        }    }

Application Context

ApplicationContext класс, который унаследован от класса DbContext. В нем прописываются все DbSet. С их помощью приложение знает, какие модели должны быть в базе данных, а какие нет.

public class ApplicationContext: DbContext    {        public DbSet<Car> Cars { get; set; }        public DbSet<Document> Documents { get; set; }        public DbSet<Worker> Workers { get; set; }        public ApplicationContext(DbContextOptions<ApplicationContext> options): base(options)        {            Database.EnsureCreated();        }    }

Настройка зависимостей и инжектирования

А теперь немного про инжектирование. Правильная настройка зависимостей проекта Asp.net core позволяет упростить его работу и избежать лишнего написания кода. Все зависимости прописываются в файле Startup.cs.

Что я связывал? Я связывал интерфейс репозитория с репозиторием каждой модели (далее будет видно, что имеется ввиду), также я связал интерфейс сервиса с его реализацией.

Также в этом же файле прописываются настройки для базы данных. Помните про строку подключения из начала статьи? Так вот сейчас мы ее и используем для настройки БД.

Вот как выглядит мой файл Startup.cs:

public Startup(IConfiguration configuration)        {            Configuration = configuration;        }        public IConfiguration Configuration { get; }        // This method gets called by the runtime. Use this method to add services to the container.        public void ConfigureServices(IServiceCollection services)        {            string connection = Configuration.GetConnectionString("DefaultConnection");            services.AddMvc();            services.AddDbContext<ApplicationContext>(options =>                options.UseSqlServer(connection));            services.AddTransient<IRepairService, RepairService>();            services.AddTransient<IBaseRepository<Document>, BaseRepository<Document>>();            services.AddTransient<IBaseRepository<Car>, BaseRepository<Car>>();            services.AddTransient<IBaseRepository<Worker>, BaseRepository<Worker>>();        }        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)        {            if (env.IsDevelopment())            {                app.UseDeveloperExceptionPage();            }            app.UseHttpsRedirection();            app.UseRouting();            app.UseAuthorization();            app.UseEndpoints(endpoints =>            {                endpoints.MapControllers();            });        }

Не забудьте создать БД перед запуском приложения. Для этого в Консоле диспетчера пакетов нужно прописать следующие команды:

Add-Migration init (или любое другое имя)

Update-Database

Поздравляю, если все шаги выполнены корректно, то вы создали свою базу данных. Также эти команды используются и для ее обновления, если ваши модели поменяются.

Тестирование

Здесь я покажу как создать UNIT-тесты для контроллера и сервиса. Для тестов я сделал отдельный проект (библиотека классов .Net Core).

Тест для контроллера

public class MainControllerTests    {        [Fact]        public void GetDataMessage()        {            var mockDocs = new Mock<IBaseRepository<Document>>();            var mockService = new Mock<IRepairService>();            var document = GetDoc();            mockDocs.Setup(x => x.GetAll()).Returns(new List<Document> { document });            // Arrange            MainController controller = new MainController(mockService.Object, mockDocs.Object);            // Act            JsonResult result = controller.Get() as JsonResult;            // Assert            Assert.Equal(new List<Document> { document }, result?.Value);        }        [Fact]        public void GetNotNull()        {            var mockDocs = new Mock<IBaseRepository<Document>>();            var mockService = new Mock<IRepairService>();            mockDocs.Setup(x => x.Create(GetDoc())).Returns(GetDoc());            // Arrange            MainController controller = new MainController(mockService.Object, mockDocs.Object);            // Act            JsonResult result = controller.Get() as JsonResult;            // Assert            Assert.NotNull(result);        }        [Fact]        public void PostDataMessage()        {            var mockDocs = new Mock<IBaseRepository<Document>>();            var mockService = new Mock<IRepairService>();            mockDocs.Setup(x => x.Create(GetDoc())).Returns(GetDoc());            // Arrange            MainController controller = new MainController(mockService.Object, mockDocs.Object);            // Act            JsonResult result = controller.Post() as JsonResult;            // Assert            Assert.Equal("Work was successfully done", result?.Value);        }        [Fact]        public void UpdateDataMessage()        {            var mockDocs = new Mock<IBaseRepository<Document>>();            var mockService = new Mock<IRepairService>();            var document = GetDoc();            mockDocs.Setup(x => x.Get(document.Id)).Returns(document);            mockDocs.Setup(x => x.Update(document)).Returns(document);            // Arrange            MainController controller = new MainController(mockService.Object, mockDocs.Object);            // Act            JsonResult result = controller.Put(document) as JsonResult;            // Assert            Assert.Equal($"Update successful {document.Id}", result?.Value);        }        [Fact]        public void DeleteDataMessage()        {            var mockDocs = new Mock<IBaseRepository<Document>>();            var mockService = new Mock<IRepairService>();            var doc = GetDoc();            mockDocs.Setup(x => x.Get(doc.Id)).Returns(doc);            mockDocs.Setup(x => x.Delete(doc.Id));            // Arrange            MainController controller = new MainController(mockService.Object, mockDocs.Object);            // Act            JsonResult result = controller.Delete(doc.Id) as JsonResult;            // Assert            Assert.Equal("Delete successful", result?.Value);        }        public Document GetDoc()        {            var mockCars = new Mock<IBaseRepository<Car>>();            var mockWorkers = new Mock<IBaseRepository<Worker>>();            var carId = Guid.NewGuid();            var workerId = Guid.NewGuid();            mockCars.Setup(x => x.Create(new Car()            {                Id = carId,                Name = "car",                Number = "123"            }));            mockWorkers.Setup(x => x.Create(new Worker()            {                Id = workerId,                Name = "worker",                Position = "manager",                Telephone = "89165555555"            }));            return new Document            {                Id = Guid.NewGuid(),                CarId = carId,                WorkerId = workerId            };        }    }

В данных тестах проверяется работа каждого метода контроллера на их корректное выполнение.

Тест для сервиса

public class RepairServiceTests    {        [Fact]        public void WorkSuccessTest()        {            var serviceMock = new Mock<IRepairService>();            var mockCars = new Mock<IBaseRepository<Car>>();            var mockWorkers = new Mock<IBaseRepository<Worker>>();            var mockDocs = new Mock<IBaseRepository<Document>>();            var car = CreateCar(Guid.NewGuid());            var worker = CreateWorker(Guid.NewGuid());            var doc = CreateDoc(Guid.NewGuid(), worker.Id, car.Id);            mockCars.Setup(x => x.Create(car)).Returns(car);            mockDocs.Setup(x => x.Create(doc)).Returns(doc);            mockWorkers.Setup(x => x.Create(worker)).Returns(worker);            serviceMock.Object.Work();            serviceMock.Verify(x => x.Work());        }        private Car CreateCar(Guid carId)        {            return new Car()            {                Id = carId,                Name = "car",                Number = "123"            };        }        private Worker CreateWorker(Guid workerId)        {            return new Worker()            {                Id = workerId,                Name = "worker",                Position = "manager",                Telephone = "89165555555"            };        }        private Document CreateDoc(Guid docId, Guid workerId, Guid carId)        {            return new Document            {                Id = docId,                CarId = carId,                WorkerId = workerId            };        }    }

В тесте для сервиса есть всего один тест для метода Work. Тут проверяется отработал этот метод или нет.

Запуск тестов

Чтобы запустить тесты достаточно зайти во вкладку Тест и нажать выполнить все тесты.

Выкладываем в Docker

В финале я покажу, как выложить данное приложение в Docker Hub. В Visual Studio 2019 это сделать крайне просто. Учтите, что у вас уже должен быть профиль в Docker и создан репозиторий в Docker Hub.

Нажимаете ПКМ на ваш проект и выбираете пункт опубликовать.

Там выбираем Docker Container Registry

На следующем окне, надо выбрать Docker Hub

Далее введите свои учетные данный Docker.

Если все прошло успешно, то осталось сделать последнюю вещь, нажать кнопку Опубликовать.

Готово, вы опубликовали свое приложение в Docker Hub!

Заключение

В данной статье я показал, как использовать возможности C# ASP.NET Core для создания простого Rest API. Показал, как создавать модели, записывать их в БД, как создать свой репозиторий, как использовать сервисы и как создавать контроллеры, которые будут отправлять JSON ответы на ваш Front. Также показал, как сделать Unit-тесты для слоев контроллеров и сервисов. И в финале показал, как выложить приложение в Docker.

Надеюсь, что данная статья будет вам полезна!

Если всю профессиональную жизнь увлеченно развивать ИТ борясь с экономным начальством, бестолковостью юзеров, ночами восстанавливать упавшие системы, начинаешь ждать пенсию как избавление. И вот УРА! Пришло время и ты вышел на пенсию. И здесь то и кроется самая засада. После небольшого отдыха наступает синдром абстиненции трудоголика. Никаких хоббей за время упорной работы не приобрел. И наступает Скука.

Все началось с решения написать игру для Андроида. И сразу стало понятно, что для игры потребуется WEB сервис. Нужно же где-то хранить успехи и поражения игрока, и, далее организовывать всякого вида соревнования. Ну может быть такое уже есть на просторах интернета? Искал, но, каюсь не слишком тщательно. Решил написать сам (заодно прокачать свои умения в WEB технологиях). Так появилось то, что я назвал Бэк офис для игр.

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

Основную идею и устройство системы вполне описывает структура сущностей определенных в ней. Итак:

• Сервер системы. Это очевидно. WEB сервер, обеспечивающий выполнение заявленные сервисы системы.

• Клиент.Игровая программа, использующая ресурсы системы.

• Администратор системы. Уникальная роль в системе. Его функции:

Общее управление системой

Просмотр содержимого объектов системы

Поддержка разработчиков (администраторов) игр

Консультации и помощь в отладке игр.

Экспорт аккаунтов разработчиков (администраторов) игр из тестовой системы в рабочую

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

Блокировка/разблокировка разработчиков и/или их игр по тем или иным причинам.

Общение с администраторами игр в чате или посредством электронной почты.

Внутрисистемный арбитраж. Разрешение спорных вопросов.

Установка и изменение курсов виртуальной валюты системы для каждого из администратора игр.

• Администратор (разработчик) игр. Уникальная роль в конкретной игре. Может быть владельцем нескольких игр. Его функции:

Создание и регистрация игр

Блокировка/разблокировка игроков

Определение стартовых ресурсов для новых игроков.

Настройка параметров игр.

Организация и ведение соревнований.

Установка курсов игровых валют.

Регулирование цен (в игровой валюте) на игровые ресурсы.

Внутри игровой арбитраж. Разрешение спорных вопросов на уровне собственных игр.

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

• Игра. Ограничивает общепринятое понятие игры следующим определением: Игра есть совокупность параметров, ресурсов, игроков и их активов полученных или выигранных игроками в процессе соревнований. Собственные обязательные свойства:

Название игры

Название игровой валюты

Стартовая сумма в единицах этой валюты при регистрации игрока в игре (стартовый бонус)

Параметр игры. Произвольный параметр, определяющий течение игры. Целое число. Разработчик имеет полную свободу назначения параметров. Параметры игры и их значения по умолчанию наследуются соревнованиями. Собственные обязательные (при создании) свойства:

1. Название.

2. Значение по умолчанию, целое.

Системой определен один фиксированный параметр, обязательный для всех соревнований. Это Количество фреймов в матче. Удалять его или создавать параметр с таким же названием нельзя, допускается только изменять его значение в конкретных соревнованиях. Этот параметр автоматически создается при создании новой игры. Кроме того, разработчик может добавить единственный на игру параметр с признаком Рейтинг. Этот параметр используется в соревнованиях как награда от администратора игры победителям, увеличивая их игровой рейтинг.

Тип игрового ресурса. Определяет перечень игровых ресурсов. Может принимать только два значения: Число и Список. Ресурс со списочным типом полезен для группировки ресурсов с числовым типом по категориям. Присутствие списочного типа необязательно.

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

Системная валюта Дублоны. Курс системной валюты устанавливается администратором системы для каждого администратора игр отдельно. Получается администратором игр при регистрации. Покупается у администратора системы. Расходуется при внутри игровых операциях в качестве комиссионных.

Игровая валюта. Может обмениваться на другие ресурсы. Получается игроком при регистрации в игре. Может покупаться у администратора игр за реальные деньги. Расходуется при покупке игровых ресурсов у администратора игры или на бирже у других игроков.

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

Соревнование. Непосредственный акт игры нескольких игроков с параметрами, настраиваемыми администратором игры. Параметры соревнования есть параметры игры с измененными значениями. Соревнования определены 3 видов: Чемпионат, Турнир, Первенство. Кроме соревнований разработчик может реализовать произвольный акт игры нескольких игроков с установкой значений параметров, определенных в игре (Свободный матч) одним из игроков. Система фиксирует состояние игрока относительно соревнования.

Фрейм. Минимальный игровой акт. Фрейм является неделимой единицей структуры любого соревнования.

Матч. Совокупность фреймов. Матч может состоять из одного или более фреймов. Иначе говоря, online встреча фиксированного состава игроков.

Раунд. Применим только к турниру. Совокупность матчей, проводимых на одном уровне

Турнир. Пирамидальная последовательность раундов. В каждом из матчей может быть только один победитель, выходящий в следующий раунд. Победитель матча определяется по вычисленным игровой программой результатам фреймов матча. Параметры могут изменяться от раунда к раунду. Собственные свойства:

• Название.

• Количество партнеров в матче (NP). От 2 до 10.

• Количество раундов (NR). От 2 до 10. Важно: NPNR общее количество игроков турнира не рекомендуется делать большим, чем 256.

• Дата окончания подписки. Регистрация игроков для участия в турнире заканчивается не позднее истечения этой даты.

• Дата начала. Турнир начинается не ранее этой даты.

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

• Вступительный рейтинг. Игрок с меньшим рейтингом не может участвовать в турнире.

• Стимул от Автора. Параметр в целых единицах игровой валюты. По умолчанию 0.

• Количество фреймов в матче. Устанавливаемое значение наследуется параметрами раундов. Количество фреймов в матче не должно быть меньше чем количество партнеров в матче.

• Количество фреймов в матче. Устанавливаемое значение наследуется параметрами раундов. Количество фреймов в матче не должно быть меньше чем количество партнеров в матче.

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

• Название.

• Количество игроков. Не рекомендуется делать большим, чем 256.

• Дата окончания подписки. Регистрация игроков для участия в чемпионате заканчивается не позднее истечения этой даты.

• Дата начала. Чемпионат начинается не ранее этой даты.

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

• Вступительный рейтинг. Игрок с меньшим рейтингом не может участвовать в турнире.

• Стимул от Автора. Параметр в целых единицах игровой валюты. По умолчанию 0.

• Количество фреймов в матче.

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

Свободный матч. Не регламентируемые администратором игры матчи между игроками. Значения параметров, определенных в игре, устанавливаются самими игроками.

Чат. Система предоставляет сервис мгновенных сообщений как между администратором игры и игроками, так и между игроками. Возможно отправлять сообщения группам игроков. Группы в чате напрямую соответствуют играм. Администратор игр состоит во всех группах, соответствующих принадлежащим ему играм. Игрок состоит во всех группах, соответствующих играм, в которых он зарегистрирован.

С более детальным описанием системы можно ознакомиться непосредственно на сайте в разделе Описание системы. Этот же сайт служит инструментом создания и управления игрой/играми для разработчика/администратора игр.

Автором предлагается также .NET Standard компонент GBOClientStd, предоставляющий все необходимые методы для доступа к API системы. Этот компонент доступен для скачивания на GitHub.

С целью проверки полноты и работоспособности системы автором написана Андроид игра головоломка под названием Медвежатник. Игра полностью подтвердила заявленные свойства системы, однако гарантировать отсутствие багов в ней автор не может гарантировать, поскольку он же и является на сегодня единственным тестировщиком как самой игры, так и системы в целом. По моему убеждению, самый плохой тестировщик это разработчик и, поэтому .apk игры выложен на 4pda по ссылке. Для тех, кто заинтересуется игрой маленькая подсказка: Головоломка решена когда все ручки на двери сейфа приобретают зеленый цвет, и таких ручек четное количество.

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

Введение. О чем эта статья.

Не так давно на Хабре я увидел статью с многообещающим названием "Что из себя представляет класс Startup и Program.cs в ASP.NET Core" (http://personeltest.ru/aways/habr.com/ru/company/otus/blog/542494/). Меня всегда нтересовало и интересует, что именно происходит под капотом той или иной библиотеки или фреймворка, с которыми мне доводится работать. И к веб-приложениям на ASP.NET Core это относится в полной мере. И я надеялся получить из этой статьи новую информацию о том, как работают упомянутые классы при запуске такого приложения. Та статья, к сожалению, меня разочаровала: в ней всего лишь в очередной раз был пересказан кусок руководства, никакой новой информации я оттуда не получил. И при чтении ее я подумал, что, наверное, есть и другие люди, которым, как и мне, интересно не просто знать, как применять тот или иной фреймворк (ASP.NET Core в данном случае), но и как он работает. А так как я по разным причинам последнее время довольно сильно углубился во внутреннее устройство ASP.NET Core, то я подумал, что теперь мне есть много что рассказать о нем из того, что выходит за рамки руководств. И вот потому я решил для начала написать статью про то, что действительно представляют из себя классы Startup и Program - так, чтобы рассказать не столько о том, как ими пользоваться (это есть в многочисленных руководствах, которые, как мне кажется, нет смысла дублировать), а, в основном, о том, как работают эти классы, причем - в контексте работы всего веб-приложения на ASP.NET Core. Однако поскольку необъятное объять нельзя, то предмет этот статьи ограничен. Прежде всего, она ограничивается рассказом только про веб-приложения, созданные с использованием нового типа шаблона приложения - Generic Host. Во-вторых, статья будет посвящена только тому, как происходит инициализация веб-приложения, потому что основная роль рассматриваемых классов именно такова - инициализация и запуск размещенного приложения. Итак, кому рассматриваемая тема, даже в столь ограниченном объеме, интересна - добро пожаловать под кат.

Введение. Продолжение.

Для начала немного расширю вводную часть статьи - потому что до ката поместилось не все, про что хотелось там написать. Но, прежде всего - краткое содержание статьи (под спойлером):

Далее, поскольку статья получилось многословной, решено было часть материала убрать с видного места, под спойлеры. Основных видов спойлеров в статье два, вот их описания:

Вернемся однако к содержанию статьи. Для начала хочется сказать о коде ASP.NET Core в целом. Не знаю как для других, а для меня стиль написания этого кода оказался весьма непривычен. Уже при первом взгляде на файлы исходного текста, которые нам любезно генерирует мастер создания нового проекта в Visual Studio видно, что программы на ASP.NET Core принято писать в "современном, модном, молодежном" стиле. И более глубокое рассмотрение самих исходных текстов ASP.NET Core это подтверждает.

Важная особенность кода ASP.NET Core, в целом, и шаблона Generic Host, в частности - широкое использование модного современного подхода (да, я специально его не называю тут по имени, почему - см. лирическое отступление), в котором написанный программистом код работает с некими интерфейсами, получаемые тем или иным методом из специального объекта фреймворка - контейнера сервисов.

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

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

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

Далее стоит упомянуть, что исторически для ASP.NET, кроме Generic Host существует другой, более старый тип шаблона веб-приложения: Web Host. Хотя производителем (Microsoft) он в рассматриваемой в статье версии ASP.NET Core (статья писалась изначально по версии 3.1.8) объявлен нежелательным для использования в новых проектах, но он все ещё поддерживается. Эти шаблоны приложения внешне весьма сходны, но в их реализации, тем не менее, есть весьма существенные отличия, рассмотрение которых заметно бы увеличило объем и так неслабо разросшейся статьи. Поэтому решено было рассмотреть в статье только реализацию шаблона Generic Host. Далее, ни работа веб-приложения, ни компоненты (Middleware), которые могут использоваться в его работе, в этой статье рассматриваться не будут по той же самой причине: необъятное объять нельзя.
Также очень кратко, только в объеме, необходимом для понимания процесса инициализации размещения (объекта, реализующего интерфейс IHost), будут рассмотрены инициализация и работа общесистемных компонентов .NET Core, таких как упомянутый выше контейнер сервисов (он же - контейнер внедрения зависимостей, DI Container), конфигурация (Configuration), параметры (Options).

И последнее, что нужно сказать во введении - про терминологию. Везде, где возможно, в статье использована русскоязычная терминология. Причем, по возможности - сделанная без помощи транслитерации, потому как шедевры транслитерации такие, как "континуация таски" (выкопано в одной прошлогодней статье на Хабре) весьма неприятно царапают мое эстетическое чувство. Однако, поскольку для немалого числа понятий в рассматриваемой области русскоязычная терминология, как минимум, не устоялась (а то и вовсе отсутствует), я, во-первых, допускаю, что использованный мной вариант может быть неудачным (или не самым удачным), а потому готов прислушиваться к комментариям об удачности терминов и о возможных альтернативах, а во-вторых, по той же причине отсутствия общепринятой русскоязычной терминологии, и чтобы в любом случае сохранить однозначность понимания, русскоязычные термины в этой статье будут дополняться их англоязычными эквивалентами - или терминами, или названиями классов - везде, где это уместно, по крайней мере - при первом их использовании. Ну, и некоторые понятия, вроде Middleware, для которых мне не удалось найти адекватный (в контексте их использования в ASP.NET) перевод, так и оставлены на языке оригинала.

На первый взгляд...

Итак, начнем с начала - с начала выполнения программы. Как известно, наверное, уже всем, выполнение программы ASP.NET начинается с определенного в файле program.cs класса Program, с его метода Main. И самый первый взгляд на этот файл, сгенерированный мастером создания нового проекта в Visual Studio, подсказывает нам, что приложение выполняется в две стадии. Сначала следует стадия настройки, производимая в шаблоне автоматически генерируемым отдельным методом CreateHostBuilder: создается вызовом статического метода CreateDefaultBuilder класса Microsoft.Extension.Hosting.Host экземпляр класса, реализующего интерфейс IHostBuilder (с добавленными к нему настройками по умолчанию), а затем с помощью методов IHostBuilder и многочисленных методов расширения IHostBuilder (специфических для различных компонентов приложения), указывается, какие компоненты, и с какими настройками будут использоваться. Отдельный метод CreateHostBuilder с этим именем нужен, как сказано в документации, чтобы средства разработки для ORM Entity Framework Core могли найти контекст подключения к БД (DbContext), с которым должно работать разрабатываемое приложение (в данной статье про это ничего не будет). Затем, уже в методе Main, вызовом метода IHostBuilder.Build создается объект, реализующий интерфейс IHost. И, наконец, приложение запускается на выполнение одним из методов интерфейса IHost или методов его расширения: в сгенерированном мастером файле используется метод расширения Run, запускающий приложение на выполнение и ожидающий его завершения, но есть и другие, альтернативные методы. Так все выглядит на первый взгляд - легко и просто.

Однако при более пристальном расмотрении все оказывается не так просто. Дело в том, что для конфигурирования веб-приложения в данном фреймворке нельзя просто взять и указать список использумых компонентов и их параметров и задать их настройки любым декларативным способом (константами/переменными/параметрами конфигурации),
а в приложение добавитьтолько тот код, который будет делать нечто специфичное именно для приложения. То тут, то там мы видим использование для конфигурирования компонентов фреймворка каких-то дополнительных блоков кода , передаваемых в виде делегатов (обычно - оформленных в виде лямбда-выражений) в вызовы каких-то методов.
Первый такой делегат встречает нас сразу же в сгенерированном мастером шаблоне простейшего веб-приложения: он используется в методе конфигурирования ConfigureWebHostDefaults для указания типа нашего класса инициализации веб-приложения, условно называемого Startup (этот класс, вообще-то, может иметь произвольное имя, поэтому дальше, чтобы не забывать этот факт, я буду называть его Startup-классом).
Т.е. в метод конфигурирования в качестве аргумента передается почему-то не просто тип Startup-класса, а некий блок кода, делегат, указывающий тип Startup-класса с помощью какого-то неочевидного соглашения: в виде лямбда-выражения, вызывающего для передаваемого в него параметра некий его обобщенный метод, специализированный типом нашего Startup-класса. А как это соглашение работает, и почему нельзя было передать в метод конфигурирования просто тип Startup-класса в качестве аргумента - это остается загадкой.

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

В документации причины использование именно такого способа передачи конфигурационной информации не объяснены никак. То, что этот делегат где-то в процессе построения приложения вызывается и выполняется - это очевидно

Но где, в какой момент, и в каких условиях это происходит - документация нам про это не рассказывает. В основном, документация по этапу конфигурирования и построения приложения ASP.NET Core является сборником рецептов "как сделать", а не описанием "как это работает".

Раскрываем тайны: этапы большого пути

Но хватит, наверное, нагнетать таинственность, а пора переходить непосредственно к рассмотрению того, как происходит процесс инициализации в шаблоне Generic Host, и почему процедура конфигурирования устроена так, как она устроена.

Общая схема процесса инициализации схематически изображена на рисунке ниже:

В изображенном на рисунке типичном процессе инициализации статический метод Host.CreateHostBuilder сначала создает объект построителя, реализующий интерфейс IHostBuilder. Затем для этого интерфейса в процессе конфигурирования вызываются (условные) присоединенные методы этого интерфейса для конфигурирования компонетов AddFeature1..AddFeatureN. В процессе конфигурирования присоединенные методы вызывают методы интерфейса IHostBuilder для регистрации делегатов, которые будут фактически выполнять конфигурирование при вызове метода Build. После окончания конфигурирования программа вызывает метод Build созданного объекта построителя, который выполняет конфигурирование. В результате этого вызова программа получает ссылку на интерфейс IHost объекта приложения (оно же - размещение, Host) и вызывает метод StartAsync этого интерфейса для запуска приложения.

Реализацией интерфейса IHostBuilder, которую создает метод CreateDefaultBuilder (статический, определен в классе Microsoft.Extensions.Hosting.Host), является класс Microsoft.Extensions.Hosting.HostBuilder(далее я буду называть его построителем, а чтобы избегать путаницы с переводом - параллельно использовать английское название интерфейса IHostBuilder). После создания построителя метод CreateDefaultBuilder добавляет в него ряд делегатов, создающих настройки по умолчанию (подробности см. в документации). Если же вам по какой-то причине эти настройки по умолчанию не нужны - вы имеете полное право создать объект построителя самостоятельно, с помощью оператора new, и конфигурировать его как угодно, что называется, "с чистого листа".

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

Для использования на некоторых из этапов конфигурирования действий, задаваемых пользователем фреймворка - тех самых "загадочных" лямбда-выражений - в этом классе определены (и создаются в конструкторе) поля, содержащие списки действий, специфичных для этапа. Эти поля представляют собой экземпляры обобщенного класса List<>, специализированные нужным типом делегата,

Далее я буду называть эти списки очередями, поскольку они используются именно как очереди: элементы добавляются в них последовательно, в конец списка, а на соответствующих этапах конфигурирования действия с содержащимися в них элементами также производятся последовательно, от первого элемента к последнему. На рис.1 очереди изображены в виде штриховых трапеций ("корзин"), и внутри них условно нарисованы находящиеся в них делегаты: стопки сплошных прямоугольников. Для добавления делегатов в каждую из очередей существует собственный метод, определенный в интерфейсе IHostBuilder и реализованный в классе построителя. На рис.1 он помечен линией с кружком вначале и стрелкой на конце, указывающей на соответствующую очередь. Конкретно о каждом поле-очереди и о соответствующем методе для добавления в него делегатов будет рассказано при описании того этапа построения, на которых они используются.

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

Ключевые компоненты Generic Host

Теперь, прежде чем двигаться дальше, нужно вкратце рассмотреть те ключевые компоненты, которые создаются в процессе построения приложения на базе шаблона Generic Host

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

Предметом же данной статьи является процесс создания конфигурации. Он происходит следующим образом: сначала в специальный объект-построитель с интерфейсом IConfigurationBuilder добавляются его методами источники конфигурации - объекты с интерфейсом IConfigurationSource. А после указания всех нужных объектов-источников конфигурации методом Build построителя конфигурации производится создание конфигурации - объекта с интерфейсом IConfiguration. Процессы добавления источников конфигурации в объект-построитель конфигурации и создания из него конфигурации детально описаны ниже, при описании соответствующих этапов инициализации приложения.

Следующий по порядку создания, но, наверное, первый по важности ключевой компонент ASP.NET Core и .NET Core - это контейнер сервисов: объект реализующий интерфейс IServiceProvider. Именно этот объект в большинстве случаев предоставляет реализации тех самых интерфейсов, который обычно используются и в коде фреймворка, и в модулях, реализующих функциональность конкретного приложения. Сервисы, которые должен предоставлять контейнер сервисов - определяются типами интерфейсов или, реже, классов, которые требуются коду. Контейнер сервисов при обращении к нему за определенным сервисом (типом интерфейса или класса) путем вызова обобщенного метода GetService с указанием нужного параметра-типа, возвращает ссылку на объект запрошенного типа - реализующий этот интерфейс или являющийся объектом этого класса.

Исходным для создания контейнера сервисов является список регистраций сервисов с интерфейсом IServiceCollection, в который методами этого интерфейса добавляются объекты - описатели сервисов. Описатели сервисов содержат такую информацию, как тип сервиса (возвращаемого класса или интерфейса), способ реализации и время жизни сервиса. Процессы добавления описателей в список регистраций сервисов и создания из него контейнера сервисов детально описаны ниже, при описании соответствующих этапов инициализации приложения.

Третий ключевой компонент ASP.NET Core и .NET Core инициализуемый в процессе создания приложения (а также - используемый внутри самого процесса инициализации) - это механизм параметров (Options). Параметры, передаваемые данным механизмом, представляют собой сервисы, позволяющие получать в приложении значения заранее определенного типа, причем на стадии инициализации (конфигурирования) приложения задается не само значение, а способ его получения, его источник. То есть, во-первых, параметры передаются в программу на стадии выполнения не как объекты данных, а как сервисы, реализованные в виде интерфейсов .NET, и реализация механизма параметров опирается на использование контейнера сервисов: сервисы для работы с параметрами, так же как и любые другие сервисы, регистрируются в списке регистраций сервисов, а затем, после создания контейнера сервисов на основе этого списка регистраций, становятся доступными в приложении. Для получения самих же передаваемых значений необходимо вызвать соответствующие свойства или методы этих сервисов (для доступа к параметрам есть три разных типа сервисов, отличающихся способами их использования - IOptions<>, IOptionsSnapshot<>, и IOptionsMonitor<>, их описание я здесь приводить не буду). Во-вторых, значения параметров являются строго статически типизированными, их типы задаются на стадии написания программы, и указываются как параметры-типы для обобщенных типов сервисов получения значений параметров(options). В-третьих, на стадии конфигурирования задаются не сами значения параметров, а способы получения их значений. Эти способы задаются путем добавления в контейнер сервисов специальных сервисов конфигурирования значений. Регистрация сервисов, реализующих механизм параметров (options), в принципе, может быть произведена обычными методами регистрации сервисов. Но для удобства конфигурирования этого механизма созданы специальные методы расширения для интерфейса списка регистрации сервисов IServiceCollection, и чаще всего используются именно они. Этими методами можно указать, что либо источником значения сервиса служит объект конфигурации, реализующий IConfiguration (обычно - раздел конфигурации), либо произвольный код, записываемый в виде одной или нескольких процедур-делегатов, устанавливающих это значение. Более подробное рассмотрение механизма параметров заслуживает отдельной статьи, поэтому здесь его не будет.

Рассмотрим теперь в подробностях процесс создания приложения, точнее - его объекта размещения (или хоста), реализующего интерфейс IHost Как уже было сказано, это производится методом Build интерфейса IHostBuilder. А поскольку статья рассматривает работу стандартной реализации шаблона приложения Generic Host построителя Microsoft.Extensions.Hosting.HostBuilder (или просто HostBuilder) здесь рассматривается работа метода Build этого конкретного класса.

Создание конфигурации приложения

Вот теперь можно вернуться к дальнешему изучению метода Build. Сначала в методе Build создается конфигурация приложения.

Для создания конфигурации приложения используются два отдельных этапа, с некоторым количеством промежуточных этапов между ними, на которых создаются другие структуры данных. Это связано с тем, что для нахождения части источников конфигурации приложения - таких, как файлы конфигурации - нужно знать некую дополнительную информацию - такую, как местонахождение корневого каталога приложения - которая обычно задается по умолчанию, но может, вообще говоря, и переопределяться в конфигурации, только в другой ее части. Поэтому сначала выполняется стадия, на которой создается конфигурация размещения (Host Configuration, чаще я буду назвать ее конфигурации построителя - по месту ее использования). Это - та часть конфигурации, которая не зависит от контекста построения (о нем немного ниже), в который входит, в частности, упомянутый путь к корневому каталогу приложения. Что именно входит в конфигурацию построителя по умолчанию - см. документацию. Очередь делегатов, выполняемых на этой стадии, создается методом ConfigureHostConfiguration интерфейса IHostBuilder и хранится во внутреннем поле _configureHostConfigActions. На рис.1 она обозначена "корзиной" под номером 1.

Создание конфигурации построителя производится внутренним методом BuildHostConfiguration().

Созданная конфигурация построителя запоминается в поле _hostConfiguration построителя.

После этого наступают этапы создания структур данных - объектов, содержащих информацию о контексте, в котором производится построение приложения. Первый такой объект - это объект окружения размещения (хоста), реализующий интерфейс IHostEnvironment. Его создание производится внутренним методом CreateHostingEnvironment(). Данный метод создает объект внутреннего для сборки типа HostingEnvironment, реализующий интерфейсы IHostEnvironment и IHostingEnvironment (устаревший аналог IHostEnvironment). При этом при создании объекта его свойства устанавливаются на основе значений ключей конфигурации размещения с фиксированными названиями (подробности - см. документацию). В число этих свойств входят имя приложения (ApplicationName), название среды выполнения(Environment) и путь к корневому каталогу приложения (ContentRootPath).
Если нужных ключей в конфигурации размещения нет - эти свойства устанавливаются в значения по умолчанию (опять-таки, см. документацию). И, наконец, в свойство ContentRootFileProvider созданного объекта окружения записывается вновь созданный экземпляр класса PhysicalFileProvider для пути ContentRootPath - то есть, в качестве средства доступа к файлам приложения используется (изначально и по умолчанию) обычная файловая система. Созданный объект окружения размещения запоминается в поле _hostingEnvironment объекта построителя.

Другой объект, содержащий информацию о контексте - это объект контекста построения (экземпляр класса HostBuilderContext) Он создается на следующем этапе внутренним методом CreateHostBuilderContext. В его свойствах запоминаются ссылки на другие объекты, связанные с построителем: в Properties - ссылка на одноименное свойство построителя - словарь построителя (его описание см. выше под спойлером "детали реализации: другие методы IHostBuilder"), в Environment - на только что созданный объект окружения размещения (IHostEnvironment), в Configuration - (временно) конфигурация размещения (потом она будет заменена на конфигурацию приложения). Ссылка на объект контекста построения запоминается в поле _hostBuilderContext. И вот теперь все готово для окончательного создания полной конфигурации приложения, включающей в себя все источники, и это становится следующей стадией.

Стадия окончательного создания конфигурации приложения производится внутренним методом BuildAppConfiguration. Очередь делегатов, выполняемых на этой стадии, создается методом ConfigureAppConfiguration интерфейса IHostBuilder и хранится во внутреннем поле _configureAppConfigActions. На рис.1 она обозначена "корзиной" под номером 2.

Следующим шагом в построитель конфигурации IConfigurationBuilder добавляется как источник конфигурации созданная ранее конфигурация построителя. Тем самым ранее созданная конфигурация построителя становится частью конфигурации приложения.

Затем построение конфигурации приложения завершается аналогично построению конфигурации построителя.

Полученная конфигурация (интерфейс IConfiguration) сохраняется в поле _appConfiguration объекта построителя.

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

Создание контейнера сервисов

Для начала - немного о том, как выглядит процесс создания контейнера сервисов. Выполняется этот вызовами двумя последовательными вызовами методов интерфейса фабрики контейнера сервисов IServiceProviderFactory. Этот интерфейс, как мы видим, является обобщенным, с параметром-типом, который является типом промежуточного объекта, создаваемого первым методом, и принимаемого вторым. Точный смысл этого параметра-типа я, честно говоря, так до конца и не понял, т.к. ни в документации, ни в изученных мной исходных текстах примеров его нетривиального использования не встречается: фабрика контейнера сервисов по умолчанию (о ней см. ниже) использует тривиальный вариант, в котором этот тип совпадает с типом списка регистраций сервисов IServiceCollection и никакого дополнительного конфигурирования с использованием этого типа не производится. В документации и в коде его в разных местах называют по-разному - то ContainerBuilder(как вышеприведенный параметр-тип, только без префикса T), то просто Container. В тексте я буду называть его "контейнер-построитель". Судя по всему, он используется где-то для конфигурирования процесса подключения контейнера сервисов стороннего типа: в .NET Core есть возможность использовать другие контейнеры сервисов, кроме реализации по умолчанию, и несколько из них официально поддерживаются, однако я со сторонними контейнерами дела не имел, а потому достоверно утверждать об этом не могу. В самой же ASP.NET Core используется только упомянутый уже тривиальный вариант по умолчанию.

Вернемся, однако, к интерфейсу фабрики контейнера сервисов IServiceProviderFactory. Первый метод, CreateBuilder, принимает в качестве аргумента список регистраций сервисов IServiceCollection services) и возвращает объект контейнера-построителя, который (я тут забегаю вперед) может быть подвергнут дополнительному конфигурированию. После этого второй метод интерфейса фабрики CreateServiceProvider принимает аргумент - контейнер-построитель и возвращает созданный на его основе контейнер сервисов (интерфейс IServiceProvider).

Для установки используемой при построения контейнера сервисов фабрики в процессе построения размещения (IHost) в интерфейсе построителя IHostBuilder существует метод UseServiceProviderFactory (его параметр тип - это тип контейнера-построителя), имеющий две перегруженных формы: первая принимает в качестве параметра ссылку на интерфейс фабрики заранее созданного объекта, вторая - делегат, принимающий в качестве параметра объект контекста построения HostBuilderContext и возвращающий ссылку на интерфейс фабрики контейнера сервисов, реализуемый объектом, который выбирается или создается на основе содержимого контекста построения на этапе создания контейнера сервисов. Ссылка на объект фабрики контейнера сервисов, которая будет использована, сохраняется во внутреннем поле построителя (на рис.1 оно обозначено штриховым кругом справа).

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

Метод CreateBuilder класса DefaultServiceProviderFactory, реализующего фабрику контейнера сервисов по умолчанию, просто возвращает переданный в него список регистраций сервисов. Метод CreateServiceProvider этого класса использует метод расширения BuildServiceProvider для интерфейса IServiceCollection.

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

Вернемся к процессу создания контейнера сервисов внутренним методом CreateServiceProvider построителя, и рассмотрим подробнее стадии этого процесса. На первой стадии создается объект списка регистраций сервисов с интерфейсом IServiceCollection - он записывается в локальную переменную services(на рис.1 она представлена штриховым прямоугольником). А потом в этот список добавляются (регистрируются) описатели сервисов, реализующих базовые сервисы фреймворка.

Кроме этих интерфейсов регистрируется (с постоянным (Singleton) временем жизни основной интерфейс приложения, построенного на шаблоне Generic Host - IHost: он реализуется внутренним классом Internal.Host, его мы затронем немного позднее.

На второй стадии создания контейнера сервисов - стадии конфигурирования списка регистраций сервисов - к созданному списку регистраций сервисов IServiceCollection применяются делегаты из очереди конфигурирования списка регистраций сервисов _configureServicesActions. На рис.1 она обозначена "корзиной" под номером 3. Для добавления делегатов в эту очередь служит метод ConfigureServices. Делегат, добавляемый в эту очередь должен принимать два параметра: контекст построения HostBuilderContext и ссылку на конфигурируемый список регистраций сервисов IServiceCollection.

На третьей стадии создания контейнера сервисов с помощью фабрики сервисов создается промежуточный объект контейнера-построителя - он записывается в локальную переменную containerBuilder (на рис.1 она представлена штриховым прямоугольником).

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

На четвертой стадии создания контейнера сервисов - стадии конфигурирования контейнера-построителя - к контейнеру-построителю применяются элементы очереди конфигурирования контейнера-построителя _configureContainerActions. На рис.1 она обозначена "корзиной" под номером 4. Для добавления элементов в эту очередь служит метод ConfigureContainer. В рассматриваемом нами случае "чистой" (без сторонних контейнеров сервисов) ASP.NET Core этот этап, похоже, не используется. Об этом, например, говорит тот факт, что в документации даже не отражена возможность использования Startup-класса на этом этапе конфигурирования, хотя поддержка метода, производящего такое конфигурирование, в коде реализована (об этом будет рассказано подробно при рассмотрении реализации метода расширения UseStartup интерфейса IWebHostBuilder).

На следующей, пятой стадии из контейнера-построителя создается объект контейнера сервисов.

На этом процесс создания контейнера сервисов внутренним методом CreateServiceProvider построителя заканчивается.

И последнее, что делает метод Build класса построителя HostBuilder - это получает из контейнера сервисов реализацию интерфейса IHost (объект класса Internal.Host), которую возвращает в качестве результата.

Что происходит потом

Последний этап инициализации приложения, компоненты которого размещены в полученном размещении IHost - этап, специфичный для каждого из компонентов. Он происходит в процессе запуска приложения, который производится методом IHost.StartAsync - прямо или косвенно, через методы расширения этого интерфейса, которые внутри себя вызывают StartAsync. Метод StartAsync стандартной реализации IHost - класса Internal.Host - запускает (уже асинхронно) каждый из размещенных компонентов приложения методом IHostedService.StartAsync: все компоненты реализуют интерфейс IHostedService. С помощью этого метода компоненты выполняют специфичную для них инициализацию. Об инициализации, выполняемым компонентом веб-приложения будет подробно рассказано во второй части статьи. Кроме того, метод StartAsync стандартной реализации IHost производит еще ряд действий, которые в данной статье не рассматриваются.

И на этом рассказ об инициализации приложения, построенного по шаблону Generic Host можно считать законченным - теперь приложение запущено и выполняется. Не правда ли, все на самом деле очень просто? Не торопитесь, в продолжении этой статьи последует рассказ об особенностях инициализации веб-приложения - и ощущение простоты, если таковое и было, обязательно развеется.

Продолжение: будет скоро опубликовано. Оно уже написано (и даже выложенно в мой блог, но в не до конца причесанном виде).

Автор: Андрей Жуков, .NET Team Leader, DataArt

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

Задача, поставленная заказчиком: Azure -> GCP

Заказчик решил перейти из одного облака (Azure) в другое (Google Cloud Platform). В некотором отдаленном будущем вообще планировалось перевести серверную часть на Node.js и развивать систему силами команды full-stack typescript-разработчиков. На момент моего входа в проект там существовала пара ASP.NET MVC приложений, которым решили продлить жизнь. Их мне и предстояло перенести в GCP.

Начальная состояние, факторы, мешающие сразу перейти на GCP

Первоначально имелось два ASP.NET MVC-приложения, которые взаимодействовали с одной общей MS SQL базой данных. Они были развернуты на Azure App Services.

Первое приложение назовем его Web Portal имело пользовательский интерфейс, построенный на базе Razor, TypeScript, JavaScript, Knockout и Bootstrap. С этими клиентскими технологиями никаких проблем не предвиделось. Зато серверная часть приложения использовала несколько сервисов, специфичных для Azure: Azure Service Bus, Azure Blobs, Azure Tables storage, Azure Queue storage. С ними предстояло что-то делать, т. к. в GCP ни один из них не поддерживается. Кроме того, приложение использовало Azure Cache for Redis. Для обработки длительных запросов была задействована служба Azure WebJob, задачи которой передавались через Azure Service Bus. По словам программиста, занимавшегося поддержкой, фоновые задачи могли выполняться до получаса.

Azure WebJobs тоже предстояло чем-то заменить. Архитектура с очередью заданий для длительных вычислений не единственное среди возможных решений можно использовать специализированные библиотеки для фоновых задач, например, Hangfire, или обратиться к IHostedService от Microsoft.

Второе приложение назовем его Web API представляло собой ASP.NET WEB API. Оно использовало только MS SQL базы данных. Вернее, в конфигурационном файле были ссылки на несколько баз данных, в реальности же приложение обращалось только к одной их них. Но об этом нюансе мне только предстояло узнать.

Оба приложения были в работающем, но плохом состоянии: отсутствовала архитектура как таковая, было много старого неиспользуемого кода, не соблюдались принципы построения ASP.NET MVC приложений и т. д. Заказчик и сам признавал низкое качество кода, а человек, изначально написавший приложения, уже несколько лет не работал в компании. Был дан зеленый свет любым изменениям и новым решениям.

Итак, нужно было перевести ASP.NET MVC приложения на ASP.NET Core 3.1, перевести WebJob c .NET Framework на .NET Core, чтобы можно было разворачивать их под Linux. Использовать Windows на GCP возможно, но не целесообразно. Надо было избавиться от сервисов, специфичных для Azure, заменить чем-то Azure WebJob, решить, как будем развертывать приложения в GCP, т. е. выбрать альтернативу Azure App Services. Требовалось добавить поддержку Docker. При этом неплохо было бы внести хоть какую-то архитектуру и поправить качество кода.

Общие принципы и соображения

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

В конце каждого этапа приложение должно находиться в стабильном состоянии, т. е. пройти хотя бы Smoke tests.

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

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

При замене сервисов Azure можно либо подобрать альтернативный GCP-сервис, либо выбрать cloud-agnostic-решение. Выбор сервисов в этом проекте и его обоснование в каждом случае мы рассмотрим отдельно.

План работ

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

1. Web Portal c ASP.NET MVC на ASP.NET Core

   1.1. Анализ кода и зависимостей Web Portal от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   1.2. Перевод Web Portal на .NET Core.

   1.3. Рефакторинг с целью устранения основных проблем.

   1.4. Merge изменений Web Portal из основной ветки репозитория, сделанных параллельно другими разработчиками.

   1.5. Докеризация Web Portal.

   1.6. Тестирование Web Portal, устранение ошибок и развертывание новой версии на Azure.

2. Web API c ASP.NET MVC на ASP.NET Core

   2.1. Написание E2E автоматических тестов для Web API.

   2.2. Анализ кода и зависимостей Web API от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   2.3. Удаление неиспользуемого исходного кода из Web API.

   2.4. Перевод Web API на .NET Core.

   2.5. Рефакторинг Web API с целью устранения основных проблем.

   2.6. Merge изменений Web API из основной ветки репозитория, сделанных параллельно другими разработчиками.

   2.7. Докеризация Web API.

   2.8. Тестирование Web API, устранение ошибок и развертывание новой версии на Azure.

3. Устранение зависимостей от Azure

   3.1. Устранение зависимостей Web Portal от Azure.

4. Развертывание в GCP

   4.1. Развертывание Web Portal в тестовой среде в GCP.

   4.2. Тестирование Web Portal и устранение возможных ошибок.

   4.3. Миграция базы данных для тестовой среды.

   4.4. Развертывание Web API в тестовой среде в GCP.

   4.5. Тестирование Web API и устранение возможных ошибок.

   4.6. Миграция базы данных для prod-среды.

   4.7. Развертывание Web Portal и Web API в prod GCP.

Целиком план представлен лишь в ознакомительных целях, далее в статье я постараюсь подробно раскрыть лишь наиболее интересные, с моей точки зрения, вопросы.

.NET Framework -> .NET Core

Перед началом переноса кода я нашел статью о миграции .Net Framework на .Net Core от Microsoft и далее ссылку на миграцию ASP.NET на ASP.NET Core.

С миграцией не-Web-проектов все обстояло относительно просто:

• преобразование формата хранения NuGet-пакетов с помощью Visual Studio 2019;

• адаптирование списка этих пакетов и их версий;

• переход с App.config в XML на settings.json и замена всех имеющихся обращений к конфигурационным значениям на новый синтаксис.

Некоторые версии NuGet-пакетов Azure SDK претерпели изменения, повлекшие несовместимость. В большинстве случаев удалось найти не всегда самую новую, зато поддерживаемую кодом .NET Core версию, которая не требовала бы изменений в логике старого программного кода. Исключением стали пакеты для работы с Azure Service Bus и WebJobs SDK. Пришлось с Azure Service Bus перейти на бинарную сериализацию, а WebJob перевести на новую, обратно несовместимую версию SDK.

C миграцией ASP.NET MVC на ASP.NET Core дело обстояло намного сложнее. Все перечисленные выше действия нужно было проделать и для Web-проектов. Но начинать пришлось с нового ASP.NET Core проекта, куда мы перенесли код старого проекта. Структура ASP.NET Core проекта сильно отличается от предшественника, многие стандартные классы ASP.NET MVC претерпели изменения. Ниже я привожу список того, что изменили мы, и большая его часть будет актуальна для любого перехода с ASP.NET MVC на ASP.NET Core.

1. Создание нового проекта ASP.NET Core и перенос в него основного кода из старого ASP.NET MVC проекта.

2. Корректировка зависимостей проекта от внешних библиотек (в нашем случае это были только NuGet-пакеты, соображения по поводу версий библиотек см. выше).

3. Замена Web.config на appsettings.json и все связанные с этим изменения в коде.

4. Внедрение стандартного механизма Dependency injection от .NET Core вместо любой его альтернативы, использовавшейся в Asp.NET MVC проекте.

5. Использование StaticFiles middleware для всех корневых папок статических файлов: изображений, шрифтов, JavaScript-скриптов, CSS-стилей и т. д.

app.UseStaticFiles(); // wwwrootapp.UseStaticFiles(new StaticFileOptions   {     FileProvider = new PhysicalFileProvider(         Path.Combine(Directory.GetCurrentDirectory(), "Scripts")),     RequestPath = "/Scripts"});

Можно перенести все статические файлы в wwwroot.

6. Переход к использованию bundleconfig.json для всех JavaScript и CSS-бандлов вместо старых механизмов. Изменение синтаксиса подключения JavaScript и CSS:

<link rel="stylesheet" href="~/bundles/Content.css" asp-append-version="true" /><script src="~/bundles/modernizr.js" asp-append-version="true"></script>

Чтобы директива asp-append-version="true" работала корректно, бандлы (bundles) должны находиться в корне, т. е. в папке wwwroot (смотри здесь).

Для отладки бандлов я использовал адаптированную версию хелпера отсюда.

7. Изменение механизма обработки UnhadledExceptions: в ASP.NET Core реализована его поддержка, остается с ней разобраться и использовать вместо того, что применялось в проекте раньше.

8. Логирование: я адаптировал старые механизмы логирования для использования стандартных в ASP.NET Core и внедрил Serilog. Последнее опционально, но, по-моему, сделать это стоит для получения гибкого structured logging c огромным количеством вариантов хранения логов.

9. Session если в старом проекте использовалась сессия, то код обращения к ней надо будем немного адаптировать и написать хелпер для сохранения любого объекта, поскольку изначально поддерживается только строка.

10. Routing: в старом проекте использовался механизм, основанный на templates, его надо было чуть-чуть подправить.

11. JSON-сериализация: В ASP.NET Core по умолчанию используется библиотека System.Text.Json вместо Newtonsoft.Json. Microsoft утверждает, что она работает быстрее предшественницы, однако, в отличие от последней, она не поддерживает многое из того, что Newtonsoft.Json умела делать из коробки безо всякого участия программиста. Хорошо, что есть возможность переключиться обратно на Newtonsoft.Json. Именно это я и сделал, когда выяснил, что большая часть сериализации в Web API была сломана, и вернуть ее в рабочее состояние с помощью новой библиотеки, если и возможно, очень непросто. Подробнее об использовании Newtonsoft.Json можно прочитать здесь.

12. В старом проекте использовался Typescript 2.3. С его подключением пришлось повозиться, потребовалось установить Node.js, подобрать правильную версию пакета Microsoft.TypeScript.MSBuild, добавить и настроить tsconfig.json, поправить файл определений (Definitions) для библиотеки Knockout, кое-где добавить директивы //@ts-ignore.

13. Код для принудительной поддержки HTTPS включается автоматически при включении этой опции в визарде проекта. Старый код, использующий пользовательский атрибут HttpsOnly, был при этом убран.

14. Все низкоуровневые действия, такие как получение параметров из body запроса, URL запроса, HTTP Headers и HttpContext потребовали изменений, т. к. API для доступа к ним претерпел изменения по сравнению с ASP.NET MVC. Работы было бы заметно меньше, если бы в старом проекте чаще использовались стандартные binding механизмы через параметры экшенов (Actions) и контроллеров (Controllers).

15. Был добавлен Swagger c помощью библиотеки Swashbuckle.AspNetCore.Swagger.

16. Нестандартный механизм Authentication потребовал рефакторинга для приведения его к стандартному виду.

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

Что делать со специфичными сервисами Azure?

После перехода на ASP.NET Core предстояло избавиться от Azure-сервисов. Можно было либо подобрать решения, которые не зависят от облачной платформы, либо найти что-то подходящее из списка GCP. Благо у многих сервисов есть прямые альтернативы у других облачных провайдеров.

Azure Service Bus мы по настоятельной рекомендации заказчика решили заменить на Redis Pub/Sub. Это достаточно простой инструмент, не настолько мощный и гибкий как, например, RabbitMQ. Но для нашего простого сценария его хватало, а в пользу такого выбора говорило то, что Redis в проекте уже использовался. Время подтвердило решение было правильным. Логика работы с очередью была абстрагирована и выделена в два класса, один из которых реализует отправку произвольного объекта, другой получает сообщения и передает их на обработку. На выделение этих объектов ушло всего несколько часов, а если сам Redis Pub/Sub вдруг потребуется заменить, то и это будет очень просто.

Azure Blobs были заменены на GCP Blobs. Решение очевидное, но все-таки различие в функциональности сервисов нашлось: GCP Blobs не поддерживает добавление данных в конец существующего блоба. В нашем проекте такой блоб использовался для создания подобия логов в формате CSV. На платформе Google мы решили записывать эту информацию в Google Cloud operations suite, ранее известный как Stackdriver.

Хранилище Azure Table Storage использовалось для записи логов приложения и доступа к ним из Web Portal. Для этого существовал логгер, написанный самостоятельно. Мы решили привести этот процесс в соответствие с практиками от Microsoft, т. е. использовать их интерфейс ILogger. Кроме того, была внедрена библиотека для структурного логирования Serilog. В GCP логирование настроили в Stackdriver.

Какое-то время проект должен был параллельно работать и на GCP, и на Azure. Поэтому вся функциональность, зависящая от платформы, была выделена в отдельные классы, реализующие общие интерфейсы: IBlobService, IRequestLogger, ILogReader. Абстрагирование логирования было достигнуто автоматически за счет использования библиотеки Serilog. Но для того, чтобы показывать логи в Web Portal, как это делалось в старом приложении, понадобилось адаптировать порядок записей в Azure Table Storage, реализуя свой Serilog.Sinks.AzureTableStorage.KeyGenerator.IKeyGenerator. В GCP для чтения логов изGoogle Cloud operations были созданы Log Router Sinks, передающие данные в BigQuery, откуда приложение и получало их.

Что делать с Azure WebJobs?

Сервис Azure WebJobs доступен только для Azure App Services on Windows. По сути он представляет собой консольное приложение, использующее специальный Azure WebJobs SDK. Зависимость от этого SDK я убрал. Приложение осталось постоянно работающим консольным и следует похожей логике:

static async Task Main(string[] args){.   var builder = new HostBuilder();  ...              var host = builder.Build();  using (host)  {     await host.RunAsync();  }...}

За всю работу отвечает зарегистрированный с помощью Dependency Injection класс

public class RedisPubSubMessageProcessor : Microsoft.Extensions.Hosting.IHostedService{...public async Task StartAsync(CancellationToken cancellationToken)...public async Task StopAsync(CancellationToken cancellationToken)...}

Это стандартный для .NET Core механизм. Несмотря на отсутствие зависимости от Azure WebJob SDK, это консольное приложение успешно работает как Azure WebJob. Оно также без проблем работает в Linux Docker-контейнере под управлением Kubernetes, о чем речь в статье пойдет позже.

Рефакторинг по дороге

Архитектура и код приложения были далеки от идеала. В ходе многих шагов постепенно производились небольшие изменения кода, который они затрагивали. Были и специально запланированные этапы рефакторинга, согласованные и оцененные вместе с заказчиком. На этих этапах мы устраняли проблемы с аутентификацией и авторизацией, переводили их на практики от Microsoft. Был отдельный этап по внесению некой архитектуры, выделению слоев, устранению ненужных зависимостей. Работа с Web API началась с этапа удаления неиспользуемого кода. При замене многих Azure-сервисов на первом этапе производилось определение интерфейсов, выделение данных зависимостей в отдельные классы.

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

Docker

С поддержкой Docker все сложилось довольно гладко. Dockerfile можно легко добавить с помощью Visual Studio. Я добавил их для всех проектов, соответствующих приложениям, для Web Portal, Web API, WebJob (который в дальнейшем превратился просто в консольное приложение). Эти стандартные Dockerfile от Microsoft не претерпели особенных изменений и заработали из коробки за единственным исключением пришлось в Dockerfile для Web Portal добавить команды для установки Node.js. Этого требует build контейнер для работы с TypeScript.

RUN apt-get update && \apt-get -y install curl gnupg && \curl -sL https://deb.nodesource.com/setup_12.x  | bash - && \apt-get -y install nodejs

Azure App Services -> GKE

Нет единственно правильного решения для развертывания .NET Core-приложений в GCP, вы всегда можете выбрать из нескольких опций:

• App Engine Flex.

• Kubernetes Engine.

• Compute Engine.

В нашем случае я остановился на Google Kubernetes Engine (GKE). Причем к этому моменту у нас уже были контейнеризованные приложения (Linux). GKE, оказалось, пожалуй, наиболее гибким из трех представленных выше решений. Оно позволяет разделять ресурсы кластера между несколькими приложениями, как в нашем случае. В принципе для выбора одного из трех вариантов можно воспользоваться блок-схемой по этой сслыке.

Выше описаны все решения по используемым сервисам GCP, кроме MS SQL Server, который мы заменили на Cloud SQL от Google.

Тестирование

Web Portal тестировался вручную, после каждого этапа я сам проводил простенький Smoke-тест. Это было обусловлено наличием пользовательского интерфейса. Если по завершении очередного этапа, новый кусок кода выпускался в Prod, к его тестированию подключались другие пользователи, в частности, Product Owner. Но выделенных QA-специалистов, в проекте, к сожалению, не было. Разумеется, все выявленные ошибки исправлялись до начала очередного этапа. Позднее был добавлен простой Puppeteer-тест, который исполнял сценарий загрузки одного из двух типов отчетов с какими-то параметрами и сравнивал полученный отчет с эталонным. Тест был интегрирован в CICD. Добавить какие-то юнит-тесты было проблематично по причине отсутствия какой-либо архитектуры.

Первым этапом миграции Web API, наоборот, было написание тестов. Для это использовался Postman, затем эти тесты вызывались в CICD с помощью Newman. Еще раньше к старому коду была добавлена интеграция со Swagger, который помог сформировать начальный список адресов методов и попробовать многие из них. Одним из следующих шагов было определение актуального перечня операций. Для этого использовались логи IIS (Internet Information Services), которые были доступны за полтора месяца. Для многих актуальных методов перечня было создано несколько тестов с разными параметрами. Тесты, приводящие к изменению данных в базе, были выделены в отдельную Postman-коллекцию и не запускались на общих средах выполнения. Разумеется, все это было параметризовано, чтобы можно было запускать и на Staging, и на Prod, и на Dev.

Тестирование позволило нам убедиться, что продукт после миграции сохранил стабильность. Конечно, идеальным вариантов было бы покрыть всю функциональность автоматизированными тестами. Поэтому в случае с Web API несмотря на гораздо большие усилия, затраченные в самом начале, миграция, поиск и исправление ошибок затем проходили гораздо легче.

Azure MS SQL -> GCP Managed MS SQL

Миграция MS SQL из Managed Azure в GCP Cloud SQL оказалась не такой простой задачей, как представлялось вначале. Основных причин тому оказался несколько:

• Очень большой размер базы данных (Azure портал показал: Database data storage /

  Used space 181GB).

• Наличие зависимостей от внешних таблиц.

• Отсутствие общего формата для экспорта из Azure и импорта в GCP Cloud SQL.

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

Перед началом миграции нужно удалить все ссылки на внешние таблицы и базы данных, иначе миграция будет неудачной. Azure SQL поддерживает экспорт только в формат bacpac, более компактный по сравнению со стандартным backup форматом. В нашем случае вышло 6 Гб в bacpac против 154 Гб в backup. Но GCP Cloud позволят импортировать только backup, поэтому нам потребовалась конвертация, сделать которую удалось лишь посредством восстановления в локальную MS SQL из bacpac и создания backup уже из нее. Для этих операций потребовалось установить последнюю версию Microsoft SQL Server Management Studio, причем локальный сервер MS SQL Server был версией ниже. Немало операций заняли по многу часов, некоторые и вовсе длились по несколько дней. Рекомендую увеличить квоту Azure SQL перед импортом и сделать копию prod базы, чтобы импортировать из нее. Где-то нам потребовалось передавать файл между облаками, чтобы ускорить загрузку на локальную машину. Мы также добавили SSD-диск на 1 Тб специально под файлы базы данных.

Задачи на будущее

При переходе с Azure App Services на GCP Kubernetes мы потеряли CICD, Feature Branch deployments, Blue/Green deployment. На Kubernetes все это несколько сложнее и требует иной реализации, но наверняка делается посредством все тех же Github Actions. В новом облаке следуем концепции Iac (Infrastructure-as-Code) вместе с Pulumi.

От старого приложения нам достались низкая производительность и слишком продолжительное время запросов к базе данных. Устранение этих проблем среди приоритетов на ближайшее будущее.