Как вы управляете конфигурацией с внедрением зависимостей?

Я большой поклонник DI / IOC. Он отлично подходит для обработки / абстрагирования жестких зависимостей и делает жизнь немного проще.

Тем не менее, у меня есть небольшой недостаток, который я не знаю, как решить.

Основная идея DI / IOC заключается в том, что при создании экземпляра объекта все его зависимости предварительно заполняются в конструкторе.

Однако ИМХО существует несколько типов параметров для конструкторов (особенно когда ваши объекты неизменны).

Зависимости (объекты, необходимые для работы вашего объекта)
Конфигурация (информация о среде, необходимой для работы)
Параметры (Данные, над которыми выполняется работа)

Я считаю, что МОК хорошо работает с зависимостями. Но я все еще пытаюсь найти лучший способ справиться с двумя другими. Тем не менее, поскольку конструктор выполняется для контейнера IOC, кажется, мне нужно поместить эти элементы в контейнер IOC.

Я хотел бы знать, какие стратегии / модели используют люди и какие преимущества и недостатки они нашли.

NB. Я знаю, что это очень субъективный вопрос, и попытался сделать его «хорошим» субъективным вопросом в соответствии с руководящими принципами SE.

design-patterns configuration-management inversion-of-control

— иСКУССТВ
источник

Под «Конфигурацией» подразумевается конфигурация среды разработки (например, Разработка или Производство)? Если это так, я обычно воспринимаю это как традиционную зависимость.

— MetaFight

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

— david.pfx

I am still trying to work out the best way to deal with the other two- передать их как обычные параметры для вашего объекта?

— Роберт Харви

@RobertHarvey неизменных объектов? Они делают отладку намного проще.

— АрЦ

Ответы:

Конфигурация (информация о среде, необходимой для работы)

Создайте класс конфигурации (чтобы быть разборчивым: интерфейс + реализация), целью которого является предоставление информации о среде. Это никак не отличает конфигурацию от других объектов, необходимых для работы вашего объекта (пункт 1).

Параметры (Данные, над которыми выполняется работа)

В объектно-ориентированной среде примитивные типы данных могут быть инкапсулированы в объекты, так что это также приводит к пункту 1. Но вы, вероятно, найдете этот вопрос SO интересным, он точно касается ситуации примитивных параметров в конструкторе при использовании DI контейнер. В данном примере дизайн может быть улучшен, что полностью исключает необходимость использования примитивных типов в конструкторе.

— Док Браун
источник

То, что я делаю, является фабричным образцом для этих случаев.

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

Напр .:

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }

— Вилем Прохазка
источник