Как избежать добавления фиктивного параметра типа только для внедрения зависимостей - PullRequest
Новая
       41

Как избежать добавления фиктивного параметра типа только для внедрения зависимостей

1 голос
/ 21 января 2020

Я работаю над рефакторингом некоторого кода. Я обнаружил, что один из моих коллег по команде создал такой интерфейс: 

public interface IConfiguration<T>
{
    string Url { get; }

    string Password { get; }
}

Этот параметр T кажется избыточным, но затем я обнаружил, что он фактически используется в конфигурации внедрения зависимостей (это ASP . NET приложение ядра 2.2), вот так: 

public override void Configure(IFunctionsHostBuilder builder)
{
     builder.Services
          .AddSingleton<IConfiguration<Person>, PersonConfiguration>()
          .AddSingleton<IConfiguration<Product>, ProductConfiguration>()
          .AddSingleton<IConfiguration<Order>, OrderConfiguration>()
}

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

Ответы [ 2 ]

2 голосов
/ 21 января 2020

Лично я бы унаследовал от интерфейса IConfiguration для каждой указанной конфигурации c (Person, Product, Order), например: 

public interface IConfiguration
{
    string Url { get; }

    string Password { get; }
}

public interface IPersonConfiguration : IConfiguration {}
public interface IProductConfiguration : IConfiguration {}
public interface IOrderConfiguration : IConfiguration {}

А затем в методе Configure: 

public override void Configure(IFunctionsHostBuilder builder)
 {
      builder.Services
           .AddSingleton<IPersonConfiguration, PersonConfiguration>()
           .AddSingleton<IProductConfiguration, ProductConfiguration>()
           .AddSingleton<IOrderConfiguration, OrderConfiguration>()
 }

Преимущества этого подхода:

  • Легко расширяемый код. Например, добавить дополнительное свойство в конфигурацию Person гораздо проще (и возможно).
  • После предыдущего пункта рефакторинг должен быть намного проще и чище.
  • (В Меньше выглядит намного чище)

Недостатки этого подхода:

  • Вам придется создать интерфейс для каждой конфигурации, что может быть немного утомительно. На мой взгляд, это сэкономит вам огромное количество времени в долгосрочной перспективе. Это техническое вложение.
0 голосов
/ 21 января 2020

ASP. NET Основной способ настройки использует шаблон параметров .

Лично я считаю "самым чистым" в форма «наименее удивительного» способа конфигурирования вещей в ASP. NET Ядро использует уже предоставленный шаблон вместо того, чтобы катить своего любимого.

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

...