Когда нам нужны IOptions?

Question

Я изучаю DI в .Net Core, и у меня нет идеи о преимуществах использования IOptions.

Зачем нам нужно IOptions, если мы можем обходиться без него?

С IOptions

interface IService
{
    void Print(string str);
}

class Service : IService
{
    readonly ServiceOption options;
    public Service(IOptions<ServiceOption> options) => this.options = options.Value;
    void Print(string str) => Console.WriteLine($"{str} with color : {options.Color}");
}

class ServiceOption
{
    public bool Color { get; set; }
} 

class Program
{
    static void Main()
    {
        using (ServiceProvider sp = RegisterServices())
        {
            //
        }
    }


    static ServiceProvider RegisterServices()
    {
        IServiceCollection isc = new ServiceCollection();

        isc.Configure<ServiceOption>(_ => _.Color = true);
        isc.AddTransient<IService, Service>();
        return isc.BuildServiceProvider();
    }
}

Без IOptions

interface IService
{
    void Print(string str);
}

class Service : IService
{
    readonly ServiceOption options;
    public Service(ServiceOption options) => this.options = options;
    public void Print(string str) => Console.WriteLine($"{str} with color : {options.Color}");
}

class ServiceOption
{
    public bool Color { get; set; }
}

class Program
{
    static void Main()
    {
        using (ServiceProvider sp = RegisterServices())
        {
            //
        }
    }

    static ServiceProvider RegisterServices()
    {
        IServiceCollection isc = new ServiceCollection();

        isc.AddSingleton(_ => new ServiceOption { Color = true });
        isc.AddTransient<IService, Service>();
        return isc.BuildServiceProvider();
    }
}

Answer 1

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

Практически, вы можете достичь того же, не используя IOptions, как вы заявили.Итак, если я вернусь на один шаг назад и посмотрим на все доступные параметры в конфигурации ядра .net:

1.Необработанная конфигурация [путь: ключ]

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

Это нехороший подход, потому что здесь нет строгой типизации при чтении конфигурации.

2.Привязка IOptions к секции конфигурации

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

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

Подробнее о преимуществах см. В статье MSDN о преимуществах.

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

3.Configuration.Bind () для привязки к разделу конфигурации

Вы можете использовать вызов .Bind для привязки раздела конфигурации к классу POCO.Вы получаете строго типизированный объект.Здесь, если несколько участников используют конфигурации, они не получат дополнительные услуги, предоставляемые интерфейсом IOptions.

Я знаю, что это не совсем указывает на разницу.Но я уверен, что это внесет немного ясности в решение ваших предпочтений.