Як ви керуєте конфігурацією із введенням залежності?

Я великий фанат DI / IOC. Він відмінно підходить для поводження / відсторонення важких залежностей і полегшує життя.

Однак у мене є невеликий захват, який я не знаю, як вирішити.

Основна ідея в DI / IOC полягає в тому, що коли об'єкт інстанціюється, всі його залежності попередньо заповнюються всередині конструктора.

Однак IMHO існує кілька типів параметрів для конструкторів (особливо, коли ваші об'єкти незмінні).

1. Залежності (Об'єкти, необхідні для роботи об'єкта)
2. Конфігурація (інформація про середовище, необхідне для роботи)
3. Параметри (Дані, над якими робиться робота)

Я вважаю, що МОК добре працює із залежностями. Але я все ще намагаюся розробити найкращий спосіб боротьби з іншими двома. Однак, оскільки запускається конструктор призначений для запуску контейнера МОК, здається, мені потрібно помістити ці елементи в контейнер МОК.

Мені хотілося б знати, які стратегії / зразки використовують люди та які переваги та недоліки люди знайшли.

NB. Мені відомо, що це дуже суб'єктивне питання, і я намагався зробити його "хорошим" суб'єктивним питанням відповідно до рекомендацій SE.

Конфігурація (інформація про середовище, необхідне для роботи)

Створіть клас конфігурації (бути вибагливим: інтерфейс + реалізація), метою якого є надання інформації про середовище. Це робить конфігурацію нічим не відрізняється від інших об'єктів, необхідних для роботи вашого об’єкта (точка 1).

Параметри (Дані, над якими робиться робота)

В об'єктно-орієнтованому середовищі примітивні типи даних можуть бути інкапсульовані в об’єкти, тому це також призводить до пункту 1. Але, ймовірно, це питання СУ буде цікавим, воно стосується саме ситуації примітивних параметрів у конструкторі, коли використовується 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);
 }