Почему мы должны создать один интерфейс для этого класса конфигурации?

Question

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

Теперь я столкнулся с одним использованием интерфейсов, которое я не получил.Это из документации ASP.NET Core, касающейся конфигурации.В частности, на странице , речь идет о настройке MongoDB с ASP.NET Core.

Они в основном определяют класс и интерфейс следующим образом:

namespace BooksApi.Models
{
    public class BookstoreDatabaseSettings : IBookstoreDatabaseSettings
    {
        public string BooksCollectionName { get; set; }
        public string ConnectionString { get; set; }
        public string DatabaseName { get; set; }
    }

    public interface IBookstoreDatabaseSettings
    {
        string BooksCollectionName { get; set; }
        string ConnectionString { get; set; }
        string DatabaseName { get; set; }
    }
}

Затем они используют это следующим образом:

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<BookstoreDatabaseSettings>(
        Configuration.GetSection(nameof(BookstoreDatabaseSettings)));

    services.AddSingleton<IBookstoreDatabaseSettings>(sp =>
        sp.GetRequiredService<IOptions<BookstoreDatabaseSettings>>().Value);

    services.AddMvc()
            .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

Я должен сказать, что не получуЭто.Объекты типа BookstoreDatabaseSettings предназначены для работы в качестве DTO для настроек.Они не предоставляют никакой функциональности вообще.Так зачем вводить один интерфейс посередине?

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

Так почему в этой ситуации, когда дело касаетсяс настройками в ASP.NET Core можно использовать интерфейсы, а не конкретный класс (например, BookstoreDatabaseSettings) напрямую?

Answer 1

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

Здесь происходит следующее: во-первых, BookstoreDatabaseSettings привязан к разделу конфигурации.Это технически все, что требуется.Однако при этом используется шаблон параметров, который означает, что вы должны затем подключить IOptions<BookstoreDatabaseSettings>, IOptionsSnapshot<BookstoreDatabaseSettings> и т. Д., А не BookstoreDatabaseSettings напрямую.Это подразумевает зависимость от Microsoft.Extensions.Options, что не обязательно является плохой вещью, но, тем не менее, это зависимость.

Следующая строка затем связывает интерфейс с фактическим экземпляром BookstoreDatabaseSettings, извлеченным из IOptions<BookstoreDatabaseSettings>,Другими словами, теперь вы можете просто ввести интерфейс вместо IOptions<BookstoreDatabaseSettings.Опять же, ничего монументального, но это абстракция использования Microsoft.Extensions.Options.Что бы это ни стоило, вы могли бы просто зарегистрировать BookstoreDatabaseSettings вместо интерфейса, чтобы получить то же самое.Тогда вы сможете ввести BookstoreDatabaseSettings напрямую, без зависимости от Microsoft.Extensions.Options.

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