Исследуем .NET 6. Часть 1 / Хабр

Глобальные события приложения

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

После генерации результата и перед отправкой результата клиенту также выполняется набор действий – сохранение страницы в кэше (если это необходимо), сохранение состояния сеанса и др. В некоторых ситуациях в разрабатываемых приложениях требуется отследить момент выполнения того или иного действия. Для этого была создана модель глобальных событий ASP.NET.

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

Ниже перечислены события, которые генерируются во время обработки каждого запроса:

Есть несколько конкретных событий, которые происходят при определенных обстоятельствах:

Конфигурация приложений

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

Из-за этого такие значения часто извлекаются из исходного кода программы и сохраняются во внешнем файле.

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

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

Такой метод сильно затруднял создание и использование приложений [2]. К вопросу о том, как хранить настройки приложения, приходилось неоднократно возвращаться в процессе разработки приложений. Никогда не существовало стандартного формата файла конфигурации, который можно было бы использовать при работе с приложением.

Платформа. NET Framework решает этот вопрос: в рамках платформы существует стандартный способ хранения конфигурации В качестве формата для хранения настроек используется XML. XML в качестве формата файлов конфигурации обладает рядом преимуществ:

Все файлы конфигурации платформы. NET имеют расширение “config”. Файлы “web.config” используются для настройки веб-приложений, а файлы “appclock” – для настольных приложений.

Файлы конфигурации организованы в целые иерархии. Ниже приведена схема, иллюстрирующая расположение файлов конфигурации.

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

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

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

В папке “C:WindowsMicrosoft. NETFramework*version CONFIG” находятся глобальные файлы конфигурации. Два файла в этой папке, machine.config и web-information scripts, имеют одинаковую структуру и оба содержат параметры конфигурации.

:/>  Программы для очистки компьютера скачать бесплатно на Windows 10

Разница между этими файлами заключается в том, что параметры из файлов “machine.config” и «web-конфигурация» можно переопределить на любом уровне иерархии.

В этой статье рассмотрим параметр, который отвечает за конкурентный доступ к веб-сервисам на основе платформы WCF. Если этот параметр указать в глобальном файле “web.config”, то он будет доступен для каждого приложения,

При этом нет необходимости определять его для каждого приложения – он уже определен.
Однако, если требуется изменить этот параметр для конкретного приложения, то это можно легко сделать переопределив этот параметр в файле “web.config” для приложения.

Однако если перенести определение этого параметра из глобального файла “web.config” в глобальный файл каталога “machine”.confirm”, то и на уровне приложения он может быть определен только функцией, которую пользователь выполняет внутри своего программного обеспечения.

Многочисленные приложения могут явно задавать политику сервера благодаря такому “жесткому” вводу параметров конфигурации. В этой ситуации приложение не сможет внести необходимые изменения в настройки сервера.

В конфигурационных файлах используется формат XML. Пример конфигурационного файла приведен ниже.

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

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

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

На этом рисунке мы выбираем секцию “MySection”. Необходимо создать класс “MyConfigSection”, который служит обработчиком параметров этой секции. Сама секция может быть определена после определения конфигурационного файла.

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

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

Это определение позволит среде исполнения. NET Framework корректно интерпретировать конфигурационную секцию в зависимости от ее назначения

Следует отметить, что все конфигурационные секции, доступные по умолчанию в .NET Framework объявлены подобным образом (используя секцию “configSections”). Эти определения сделаны в глобальном файле “machine.config”.

Далее, доступ к уже существующим разделам конфигурации обеспечивает объект WebConfigurationManager. Для этого сначала можно получить объект Confugion с помощью статического метода “OpenWebConfiguration”, а затем использовать метод “GetSection” для доступа к определенному разделу.

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

Конфигурация приложений в .net 5

В.NET 5 предусмотрено несколько вариантов конфигурации, но есть два основных типа, которые вы используете в своих приложениях:

Интерфейс IConfigurationBuilder представляет собой обёртку для списка источников конфигурации. Поставщики конфигурации часто включают методы расширения (например, AddJsonFile()) и AddsAzureKeyVault().

:/>  8GadgetPack v.20.0 (2016) MULTi / Русский скачать через торрент бесплатно

public interface IConfigurationBuilder{IDictionary Properties { get; }IList Sources { get; }IConfigurationBuilder Add(IConfigurationSource source);IConfigurationRoot Build();}

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

Менеджер конфигурации в .net 6

Новый тип конфигурации под названием ConfigurationManager IConfigurationBuilder был представлен в. NET, и он реализует как BigRoot, так и SkinServer. Этот типичный сценарий из предыдущего раздела может быть оптимизирован путем объединения обеих реализаций в один тип.

Когда вы добавляете IConfigureSource в ConfigurationManager, поставщик загружается сразу, а конфигурация обновляется. В сценарии частичной сборки это позволяет избежать загрузки источников конфигурации более одного раза.

Применить это на практике сложнее, чем кажется. Технически говоря, COM-порты можно использовать для управления интерфейсом IList;

public interface IConfigurationBuilder{IList Sources { get; }// … другие члены }

Проблема с ConfigurationManager заключается в том, что IList позволяет использовать методы Add() и Remove (). Если бы был простой List, потребители могли вводить и удалять поставщиков конфигурации без участия ConfigurationManager.

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

private class ConfigurationSources : IList{private readonly List _sources = new();private readonly ConfigurationManager _config;

  public ConfigurationSources(ConfigurationManager config){_config = config;}

  public void Add(IConfigurationSource source){_sources.Add(source);// добавляет источник в ConfigurationManager_config.AddSource(source);}

  public bool Remove(IConfigurationSource source){var removed = _sources.Remove(source);// перезагрузка источников в ConfigurationManager_config.ReloadSources();return removed;}

  // … остальная реализация}

Каждый раз при добавлении нового источника ConfigurationManager следит за тем, чтобы вызывалась функция AddSource(). Данные источника могут быть быстро получены благодаря ConfigurationManager.

public class ConfigurationManager{private void AddSource(IConfigurationSource source){lock (_providerLock){IConfigurationProvider provider = source.Build(this);_providers.Add(provider);provider.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() => provider.GetReloadToken(), () => RaiseChanged()));}

    RaiseChanged();}}

Это позволяет IConfigurationSource создавать Build on API Sourc для создания нового программного обеспечения цепочки поставок.

Затем вызывается IConfigurationProvider. Load(). Данные загружаются в провайдер (например, из файла в Azure Key Vault или переменных среды), и это дорогостоящий шаг! Это лучший выбор в “нормальной” ситуации, когда вы просто добавляете источники в IConfigurationBuilder и если вам нужно собрать его более одного раза.

Реализация Build() в ConfigurationManager теперь пустая, просто возвращает себя.

IConfigurationRoot IConfigurationBuilder.Build () => this;

Конечно, компромиссы – необходимая часть разработки программного обеспечения. Если вы только добавляете источники, инкрементное создание источников – это фантастика. Однако ConfigurationManager должен вызывать ReloadSources(), если вы вызываете любую из функций ILists или indexers.

private void ReloadSources(){lock (_providerLock){DisposeRegistrationsAndProvidersUnsynchronized();

    _changeTokenRegistrations.Clear();_providers.Clear();

    foreach (var source in _sources){_providers.Add(source.Build(this));}

    foreach (var p in _providers){p.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() => p.GetReloadToken(), () => RaiseChanged()));}}

  RaiseChanged();}

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

Однако удаление источников — это довольно странная операция, и ее можно провести с помощью ConfigurationManager. кто мог бы подумать? 😉

Сравнительная стоимость различных операций при использовании ConfigurationBuilder и ConfarmManager приведена в следующей таблице.

:/>  Core Temp - мониторинг температуры процессора [ОБЗОР]

От переводчика

* Несмотря на то, что разработчики. NET больше не используют слово Core в названии и автор использует его для названия приложения

P S: Пожалуйста, не будьте суровы в своих оценках; это мой первый перевод для “Хабры”. В будущем я переведу больше статей из этого сборника.

Проблема “частичной сборки конфигурации” в .net 5

Проблема обычно возникает, когда вам нужно “частично” создать конфигурацию. Когда вы храните свою конфигурацию в такой службе, как Azure Key Vault, вы часто сталкиваетесь с подобными проблемами.

В этом разделе приведены рекомендации для чтения секретов Azure Key Vault внутри ConfigureAppConfiguration() в ASP. NET Core:

.ConfigureAppConfiguration((context, config) =>{// “нормальная” конфигурацияconfig.AddJsonFile(“appsettings.json”);config.AddEnvironmentVariables();

Стоит ли беспокоиться о configurationmanager?

После того, как все установлено, нужно ли еще беспокоиться об использовании ConfigurationManager или configureBuilder?

Скорее да.

Новый WebApplicationBuilder, представленный в. NET 6 использует ConfigurationManager для случая использования, который я описал выше: когда вам необходимо частично построить конфигурацию.

Однако WebHostBuilder или Host Builder, представленные в более ранних версиях ASP. NET Core (в отличие от АSP) 6 и по-прежнему использующие типы ConfigurationMoot.

Единственная ситуация, которую я могу представить, когда вам нужно быть осторожным, — это если вы где-то полагаетесь на то, что IConfigurationBuilder или IConfigurationRoot представлены в виде конкретных типов ConfigurationBuilder или ConfigurationRoot. Мне это кажется маловероятным, и, если вы полагаетесь на это, мне было бы интересно узнать, почему!

Но, кроме этого единственного исключения, старые типы никуда не денутся. Просто порадуйтесь, что если вам нужно выполнить «частичную сборку» и вы используете новый WebApplicationBuilder — ваше приложение будет немного лучше работать.

Краткие итоги

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

Существует иерархия конфигурационных файлов. Параметры, определенные в machine.config, могут быть изменены только внутри программы; их нельзя изменить на уровне приложения. На глобальном уровне есть два файла: файлы веб-интерфейса.

Файлы конфигурации могут быть унаследованы на уровне приложения. Для создания собственного раздела конфигурации необходимо создать класс-обработчик и объявить собственный раздел конфигурации в разделе “configSections”. Объект, представляющий объект веб-конфигурации, содержит компонент WebConfigurationManager.

Итого

В этой статье я расскажу о новом типе ConfigurationManager, который был добавлен в. NET 6 и используется новым минимальным API APs. ConfigurationManager был создан для улучшения распространенной ситуации, когда вам нужно “частично собрать” конфигурацию.

Загружая источники сразу после их добавления и не дожидаясь вызова Build(), ConfigurationManager ускоряет этот сценарий. В сценарии “частичной сборки” это предотвращает необходимость “пересборки” конфигурации. Стоимость некоторых операций (например, удаление источников) является компромиссом.

Оригинал

Оставьте комментарий

Adblock
detector