Jak zarządzasz konfiguracją z wstrzykiwaniem zależności?

Jestem wielkim fanem DI / IOC. Doskonale nadaje się do radzenia sobie z abstrakcyjnymi zależnościami i ułatwia życie.

Mam jednak niewielką wadę, której nie jestem pewien, jak rozwiązać.

Podstawową ideą w DI / IOC jest to, że gdy instancja obiektu jest tworzona, wszystkie jego zależności są wstępnie wypełniane w konstruktorze.

Jednak IMHO ma kilka rodzajów parametrów dla konstruktorów (szczególnie gdy twoje obiekty są niezmienne).

1. Zależności (obiekty wymagane do działania obiektu)
2. Konfiguracja (informacje o środowisku wymaganym do pracy)
3. Parametry (dane, na których praca jest wykonywana)

Uważam, że MKOl działa dobrze z zależnościami. Ale wciąż próbuję znaleźć najlepszy sposób na radzenie sobie z pozostałymi dwoma. Ponieważ jednak konstruktor jest uruchamiany w kontenerze IOC, wydaje się, że muszę umieścić te elementy w kontenerze IOC.

Chciałbym wiedzieć, jakie strategie / wzorce stosują ludzie oraz jakie zalety i wady znaleźli ludzie.

NB. Wiem, że jest to pytanie bardzo subiektywne i starałem się, aby było to „dobre” pytanie subiektywne zgodnie z wytycznymi SE.

Konfiguracja (informacje o środowisku wymaganym do pracy)

Utwórz klasę konfiguracji (do wyboru: interfejs + implementacja), której celem jest dostarczenie informacji o środowisku. To sprawia, że ​​konfiguracja w żaden sposób nie różni się od innych obiektów wymaganych do działania obiektu (punkt 1).

Parametry (dane, na których praca jest wykonywana)

W środowisku zorientowanym obiektowo prymitywne typy danych mogą być enkapsulowane w obiektach, więc prowadzi to również do punktu 1. Ale prawdopodobnie to pytanie SO będzie interesujące, dotyczy dokładnie sytuacji prymitywnych parametrów w konstruktorze, gdy używasz DI pojemnik. W podanym przykładzie projekt mógłby zostać ulepszony, co pozwoliło całkowicie uniknąć potrzeby prymitywnych typów w konstruktorze.

To, co robię, to wzór fabryczny dla tych przypadków.

Nie używam samego obiektu jako zależności, ale tworzę obiekt fabryczny za pomocą metody Get, która akceptuje parametry, których kontener nie może automatycznie powiązać.

Dawny.:

 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);
 }