Получение IConfiguration из ServiceCollection

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

public static IServiceCollection AddApi(this IServiceCollection services, IConfiguration databaseConfiguration)
{  
  services.Configure<DatabaseOptions>(databaseConfiguration);
}

из класса StartUp вызов выглядит так

public void ConfigureServices(IServiceCollection services)
{
  services.AddApi(Configuration.GetSection("Database"));
  services.AddMvc();
}

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

Имхо, это плохой дизайн для доступа к IConfiguration из любого места, кроме корня композиции (класс Startup для ядра ASP.NET), поскольку это подразумевает, что файл конфигурации должен иметь определенную структуру, которую вообще нельзя изменить. Вместо этого я бы написал метод расширения для настройки классов конфигурации внутри корня композиции и передачи объекта IConfiguration, аналогично тому, как .Configure(Configuration.GetSection("MyLibConfi‌​g"). Таким образом, разработчик, составляющий свое приложение, из ваших компонентов может решить, где разместить его в appsettings.json

Или как бы вы разрешили конфликты, когда две библиотеки напрямую ссылаются на IConfiguration и имеют один и тот же раздел в конфигурации? то есть JsonSettings, но имеют совершенно другую структуру? Это можно решить, только позволив разработчику, составившему его, выбрать и передать имя раздела вашему методу расширения, который устанавливает параметры через .Configure.

Чтобы получить IConfiguration из IServiceCollection, почему бы просто не разрешить зависимость?:

IConfiguration configuration = services.BuildServiceProvider().GetService<IConfiguration>();

Я создал свой собственный тип «коллекции сервисов», который обернул IServiceCollection и IConfiguration, и все мои модули используют этот тип для регистрации своих сервисов. Например:

public interface IMyServiceCollection
{
    public IServiceCollection Services { get; set; }

    public IConfiguration Configuration { get; set; }
}

public static void AddFooModule(this IMyServiceCollection myServices)
{
    var services = myServices.Services;
    var config = myServices.Configuration;
}

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

public static IMyServiceCollection CreateServiceCollection(this IServiceCollection services, IConfiguration config)
{
    return new MyServiceCollection 
    { 
        Services = services,
        Configuration = config
    };
}

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

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