Como você gerencia a configuração com injeção de dependência?

15

Eu sou um grande fã de DI / IOC. É ótimo para lidar com / abstrair as dependências difíceis e torna a vida um pouco mais fácil.

No entanto, tenho uma pequena reclamação, que não sei como resolver.

A idéia básica em DI / IOC é que quando um objeto é instanciado, todas as suas dependências são pré-preenchidas dentro do construtor.

No entanto IMHO existem vários tipos de parâmetros para construtores (especialmente quando seus objetos são imutáveis).

  1. Dependências (Objetos necessários para o seu objeto fazer o trabalho)
  2. Configuração (informações sobre o ambiente necessário para o trabalho)
  3. Parâmetros (dados em que o trabalho é feito)

Acho que o COI funciona bem com dependências. Mas ainda estou tentando descobrir a melhor maneira de lidar com os outros dois. No entanto, como o construtor é executado para ser executado pelo contêiner IOC, parece que preciso colocar esses itens no contêiner IOC.

Eu gostaria de saber quais estratégias / padrões as pessoas empregam e quais vantagens e desvantagens as pessoas encontraram.

NB. Estou ciente de que esta é uma questão altamente subjetiva, e tentei torná-la uma questão subjetiva "boa", de acordo com as diretrizes da SE.

    
por ArTs 10.02.2014 / 11:36
fonte

2 respostas

9

Configuration (information about the environment required to do work)

Crie uma classe de configuração (para ser exigente: uma interface + uma implementação) cujo objetivo é fornecer as informações sobre o ambiente. Isso faz com que a configuração não seja diferente de outros objetos necessários para o seu objeto fazer o trabalho (ponto 1).

Parameters (Data that work is done on)

Em um ambiente orientado a objetos, os tipos de dados primitivos podem ser encapsulados em objetos, portanto, isso também leva ao ponto 1. Mas você provavelmente encontrará isso SO pergunta interessante, ele lida exatamente com a situação de parâmetros primitivos em um construtor, ao usar um contêiner DI . No exemplo dado, o design poderia ser melhorado, o que evitou completamente a necessidade de tipos primitivos no construtor.

    
por 10.02.2014 / 13:33
fonte
1

O que eu faço é um padrão de fábrica para esses casos.

Eu não uso o objeto em si como uma dependência, mas crie um objeto de fábrica com um método Get que aceite parâmetros que não podem ser vinculados automaticamente pelo contêiner.

Ex .:

 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);
 }
    
por 14.02.2014 / 20:04
fonte