В рамках разработки продукта Docs Security Suit мы столкнулись с задачей хранения множества разнотипных настроек приложения как в БД, так и в конфигах. Да и еще так, чтобы их можно было удобно читать-писать. Здесь нам поможет интерфейс IConfiguration, тем более, что он универсальный и удобный для использования, что позволит хранить всевозможные настройки в одном месте

Определяем задачи

В ASP.Net Core приложениях появилась возможность работать с настройками приложения через интерфейс IConfiguration. По работе с ним написано не мало статей. Эта статья расскажет об опыте использования IConfiguration для хранения настроек нашего приложения, таких как настройки подключение к LDAP серверу, к SMTP серверу и т.п. Цель — настроить существующий механизм работы с конфигурациями приложения на работу с БД. В этом материале вы не найдете описание стандартного подхода использования интерфейса.

Архитектура приложения построена у нас по DDD в сцепке с CQRS. К тому же, мы знаем, что объект интерфейса IConfiguration хранит все настройки в виде пары “ключ-значение”. Поэтому, мы вначале описали некую сущность настроек на домене в таком виде:

public class Settings: Entity
    {
        public string Key { get; private set; }

        public string Value { get; private set; }

        protected Settings() { }

        public Settings(string key, string value)
        {
            Key = key;
            SetValue(value);
        }

        public void SetValue(string value)
        {
            Value = value;
        }
    }

В качестве ORM в проекте используется EF Core. А за миграции отвечает FluentMigrator.
Добавляем новую сущность в наш контекст:

public class MyContext : DbContext
    {
        public MyContext(DbContextOptions options) : base(options)
        {
        }

        public DbSet<Settings> Settings { get; set; }

	…
    }

Далее для нашей новой сущности нужно описать конфигурацию EF:

internal class SettingsConfiguration : IEntityTypeConfiguration<Settings>
    {	
        public void Configure(EntityTypeBuilder<Settings> builder)
        {
            builder.ToTable("Settings");
        }
    }

И написать миграцию для этой сущности:

[Migration(2019020101)]
public class AddSettings: AutoReversingMigration
    {
        public override void Up()
        {
            Create.Table("Settings")
                .WithColumn(nameof(Settings.Id)).AsInt32().PrimaryKey().Identity()
                .WithColumn(nameof(Settings.Key)).AsString().Unique()
                .WithColumn(nameof(Settings.Value)).AsString();
        }
    }

А где же тут упомянутый IConfiguration?

Применяем интерфейс IConfigurationRoot

В нашем проекте есть api приложение построенное на ASP.NET Core MVC. И по умолчанию, мы используем IConfiguration для стандартного хранения настроек приложения, например подключения к БД:

public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

       public IConfiguration Configuration { get; }
       public void ConfigureServices(IServiceCollection services)
        {
            void OptionsAction(DbContextOptionsBuilder options) => options.UseSqlServer(Configuration.GetConnectionString("MyDatabase"));

            services.AddDbContext<MyContext>(OptionsAction);

	...
        }

Эти настройки хранятся по умолчанию в переменных среды окружения:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
           .ConfigureAppConfiguration((hostingContext, config) =>
           {
               config.AddEnvironmentVariables();
           })

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

Для того чтобы отделить подключенные объекты в DI, решили использовать дочерний интерфейс IConfigurationRoot:

public void ConfigureServices(IServiceCollection services)
        {
            services.AddScoped<IConfigurationRoot>();
	...
        }

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

Однако, наш объект в контейнере ничего не знает про нашу сущность в домене и как работать с БД.

Описываем нового провайдера конфигурации

Напомним, что наша задача — хранить настройки в БД. А для этого нужно описать нового провайдера конфигурации IConfigurationRoot, унаследованного от ConfigurationProvider. Для корректной работы нового провайдера, мы должны описать метод чтения из БД — Load() и метод записи в БД — Set():

public class EFSettingsProvider : ConfigurationProvider
    {
        public EFSettingsProvider(MyContext myContext)
        {
            _myContext = myContext;
        }

        private MyContext _myContext;

        public override void Load()
        {
            Data = _myContext.Settings.ToDictionary(c => c.Key, c => c.Value);
        }

        public override void Set(string key, string value)
        {
            base.Set(key, value);

            var configValues = new Dictionary<string, string>
            {
                { key, value }
            };

            var val = _myContext.Settings.FirstOrDefault(v => v.Key == key);

            if (val != null && val.Value.Any())
                val.SetValue(value);
            else
                _myContext.Settings.AddRange(configValues
                    .Select(kvp => new Settings(kvp.Key, kvp.Value))
                    .ToArray());

            _myContext.SaveChanges();
        }
    }

Далее, необходимо описать новый source для нашей конфигурации, который реализует IConfigurationSource:

public class EFSettingsSource : IConfigurationSource
    {
        private DssContext _dssContext;

        public EFSettingSource(MyContext myContext)
        {
            _myContext = myContext;
        }

        public IConfigurationProvider Build(IConfigurationBuilder builder)
        {
            return new EFSettingsProvider(_myContext);
        }
    }

И для простоты, добавляем расширение к IConfigurationBuilder:

public static IConfigurationBuilder AddEFConfiguration(
            this IConfigurationBuilder builder,
            MyContext myContext)
        {
            return builder.Add(new EFSettingSource(myContext));
        }

Теперь, мы можем указать описанного нами провайдера в месте, где мы подключаем объект к DI:

public void ConfigureServices(IServiceCollection services)
        {
            services.AddScoped<IConfigurationRoot>(provider =>
            {
                var myContext = provider.GetService<MyContext>();
                var configurationBuilder = new ConfigurationBuilder();
                configurationBuilder.AddEFConfiguration(myContext);
                return configurationBuilder.Build();
            });

	...
        }

Что же нам дали наши манипуляции с новым провайдером?

Примеры использования IConfigurationRoot

Для начала определим некую модель Dto, которая будет транслироваться клиенту нашего приложения, например для хранения настроек подключения к ldap:

public class LdapSettingsDto
    {
        public int Id { get; set; }

        public string UserName { get; set; }

        public string Password { get; set; }

        public string Address { get; set; }
    }

Из “коробки” IConfiguration хорошо умеет записывать и читать один экземпляр объекта. А для работы с коллекцией нужны небольшие доработки.

Для хранения нескольких однотипных объектов, мы написали расширение для IConfigurationRoot:

public static void SetDataFromObjectProperties(this IConfigurationRoot config, object obj, string indexProperty = "Id")
        {
            //Получаем тип объекта
            var type = obj.GetType();
            int id;
            try
            {
                //Получаем индекс экземпляра
                id = int.Parse(type.GetProperty(indexProperty).GetValue(obj).ToString());
            }
            catch (Exception ex)
            {
                throw new Exception($"Ошибка чтения свойства {indexProperty} объекта {type.Name}", ex.InnerException);
            }

            //Если индекс равен 0, то пробуем найти максимальный индекс в коллекции и присвоить его свойству indexProperty
            if (id == 0)
            {
                var maxId = config.GetSection(type.Name)
                    .GetChildren().SelectMany(x => x.GetChildren());
                var mm = maxId
                    .Where(c => c.Key == indexProperty)
                    .Select(v => int.Parse(v.Value))
                    .DefaultIfEmpty()
                    .Max();
                id = mm + 1;

                try
                {
                    type.GetProperty(indexProperty).SetValue(obj, id);
                }
                catch (Exception ex)
                {
                    throw new Exception($"Ошибка записи свойства {indexProperty} объекта {type.Name}", ex.InnerException);
                }
            }

            //Бежим по свойствам объекта и записываем их в коллекцию
            foreach (var field in type.GetProperties())
            {
                var key = $"{type.Name}:{id.ToString()}:{field.Name}";
                
                if (!string.IsNullOrEmpty(field.GetValue(obj)?.ToString()))
                {
                    config[key] = field.GetValue(obj).ToString();
                }
            }
        }

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

Пример записи настроек в БД

Как было упомянуто выше, в нашем проекте используется подход CQRS. Для записи настроек опишем простую команду:

public class AddLdapSettingsCommand : IRequest<ICommandResult>
    {
        public LdapSettingsDto LdapSettings { get; }

        public AddLdapSettingsCommand(LdapSettingsDto ldapSettings)
        {
            LdapSettings = ldapSettings;
        }
    }

А затем и обработчик нашей команды:

public class AddLdapSettingsCommandHandler : IRequestHandler<AddLdapSettingsCommand, ICommandResult>
    {
        private readonly IConfigurationRoot _settings;

        public AddLdapSettingsCommandHandler(IConfigurationRoot settings)
        {
            _settings = settings;
        }

        public async Task<ICommandResult> Handle(AddLdapSettingsCommand request, CancellationToken cancellationToken)
        {
            try
            {
                _settings.SetDataFromObjectProperties(request.LdapSettings);
            }
            catch (Exception ex)
            {
                return CommandResult.Exception(ex.Message, ex);
            }

            return  await Task.Run(() => CommandResult.Success, cancellationToken);
        }
    }

В итоге мы одной строчкой можем записывать данные наших настроек ldap в БД в соответствии с описанной логикой.

В БД же наши настройки выглядят так:

Пример чтения настроек из БД

Для чтения настроек ldap мы напишем простой запрос:

public class GetLdapSettingsByIdQuery : IRequest<LdapSettingsDto>
    {
        public int Id { get; }

        public GetLdapSettingsByIdQuery(int id)
        {
            Id = id;
        }
    }

А затем и обработчик нашего запроса:

public class GetLdapSettingsByIdQueryHandler : IRequestHandler<GetLdapSettingsByIdQuery, LdapSettingsDto>
    {
        private readonly IConfigurationRoot _settings;

        public GetLdapSettingsByIdQueryHandler(IConfigurationRoot settings)
        {
            _settings = settings;
        }

        public async Task<LdapSettingsDto> Handle(GetLdapSettingsByIdQuery request, CancellationToken cancellationToken)
        {
            var ldapSettings = new List<LdapSettingsDto>();
            _settings.Bind(nameof(LdapSettingsDto), ldapSettings);
            var ldapSettingsDto = ldapSettings.FirstOrDefault(ls => ls.Id == request.Id);

            return await Task.Run(() => ldapSettingsDto, cancellationToken);
        }
    }

Как видим из примера, с помощью метода Bind, мы наполняем наш объект ldapSettings данными из БД — по названию LdapSettingsDto мы определяем ключ (секцию) по которому нужно получить данные и далее происходит вызов метода Load, описанного в нашем провайдере.

А что далее?

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

Мы надеемся, что наше решение вам будет полезно и вы поделитесь с нами вашими вопросами и замечаниями.