Será que um contêiner IoC substituir o uso de Fábricas

Question

Eu estou apenas começando com recipientes de IoC então desculpas se isso é uma pergunta estúpida.

Eu tenho o código como o seguinte em um aplicativo

internal static class StaticDataHandlerFactory
    {
        public static IStaticDataHandler CreateHandler(StaticDataUpdate staticDataUpdate)
        {
            if (staticDataUpdate.Item is StaticDataUpdateOffice)
            {
                return new OfficeUpdateHandler();
            }

            if (staticDataUpdate.Item is StaticDataUpdateEmployee)
            {
                return new EmployeeUpdateHandler();   
            }

            if (staticDataUpdate.Item == null)
            {
                throw new NotImplementedException(
                    string.Format("No static data provided"));
            }
            else
            {
                throw new NotImplementedException(
                    string.Format("Unimplemented static data type of {0}", staticDataUpdate.Item.GetType().FullName));
            }
        }
    }

É basicamente uma fábrica simples que retorna a estratégia correta para lidar com os dados de entrada.

Será que um contêiner IoC me permita eliminar código como este? Ou seja: será que me permita escolher dinamicamente uma implementação concreta de carga com base no tipo de um parâmetro de entrada

Ou eu sou maneira fora do curso aqui?

Answer 1

Na verdade, embora seja possível substituir parte do código com uma inversão do sistema de controle, não é óbvio para mim que é uma boa ideia. Injeção de dependência tende a ser melhor para a configuração de sistemas, e não a criação dinâmica de objetos. Para colocá-lo de forma diferente, o recipiente em si é um enorme variável global e, como tal, deve aparecer em grande parte do seu código.

Como um aparte, o código parece estar a violar a Lei de Demeter . Parece que o parâmetro deve ser do tipo "StaticDataUpdateItem" em vez de "StaticDataUpdate". Com o observado, há uma muito forte argumento para reescrever esse código como uma chamada de método na StaticDataUpdateItem.

Eu costumava IoC muito fortemente, mas a criação de objetos dinâmica ainda é melhor tratada com o uso de um padrão de fábrica abstrata. Em suma, se você não gosta da idéia de adicionar um método para o próprio item para gerar o identificador, o código é provavelmente melhor deixar do jeito que está.

Answer 2

Você não está longe do curso em tudo; a maneira que eu entendo, você está muito perto.

A maneira que eu iria mais comumente estruturar este tipo de coisa é transformar sua classe de fábrica em seu recipiente IoC, simplesmente permitindo que as UpdateHandlers que são devolvidos a ser especificado usando Dependency Injection. Então, ao invés de ter a lógica em seu código que especifica que os meios StaticDataUpdateOffice para retornar OfficeUpdateHandler, você pode transformar o seu código em simplesmente dizendo que StaticDataUpdateOffice retorna qualquer um (recém-especificada) variável m_officeUpdateHandler contém; desde que o seu Quadro garante que você definir o valor da m_officeUpdateHandler antes de invocar a sua fábrica, você está pronto para ir. E você pode alterar o valor do m_officeUpdateHandler a qualquer coisa que você quer em tempo de execução como a sua mudança necessidades.

Esta Dependency Injection permite que você tenha controle sobre a inversão do processo de Controle; você pode ter uma fábrica simples que retorna seus manipuladores, e você pode abstrair a lógica que controla o manipulador se voltou para um local diferente, conforme o caso.

Nota:. Minha experiência com esse tipo de coisa é muito fortemente impulsionado pela minha experiência (muito positivo) com a Primavera, e assim que podem colorir a minha interpretação da sua pergunta (ea resposta)

Answer 3

A resposta curta é sim, ele permite. mostra esta postagem no blog uma maneira lisa para escolher implementação em tempo de execução usando Windsor. O autor, Ayende, elabora aqui e aqui .

Eu não tentei isso ainda, mas espero que em breve.

Answer 4

Concordo com as outras respostas aqui, que sim, você pode fazê-lo dessa forma. Mas, por que você não use um genérico?

public static IStaticDataHandler CreateHandler<T>( params object[] args )
{...

onde args pode ser passado como os argumentos ctor (para, por exemplo, Activator).

Answer 5

Eu ainda tenho que ler todas as palavras aqui que faz muito sentido.

IoC é mais para configuração?

criação do objeto dinâmico é melhor do que? Genéricos? Isso tudo é fora de tópico.

1) IoC é nada, mas um bom tempo saver comparado a implementação da 'composição sobre especialização herança /' evangelho.

Assim regra # 1 para usar um IoC é que você deve estar muito cansado de ter que lidar com longas construtores que seguem o 'se ligam a contrato não implementação'.

Dito de outra forma, este é o padrão stratey como a alternativa mais que a configuração padrão, pelas mesmas razões (encapsular ...) ... mas é mais trabalho para criar todos os tipos de interface do Extra / abstratas e é mais trabalho para fazê-lo cada vez com toda a IServiceProvicerThis e IResolverThat ... Se você não está cansado de ter que tediosamente cumprir os contratos de código tais como:

IInterestingService interessante = ... você começa uma instância no entanto ..

adicionar cerca de mais três linhas como este ..

então

serviço IAmazementService = new AmazementService (interessante, thesecondstrategy, thethird, etc ...)

Isso fica velho. Então IoC nunca é uma questão porque ninguém inteligente o suficiente para código usando design sólido saberia melhor. Aqueles pedindo ter todas as respostas erradas.

Então, se de fato você se encontra acima, em seguida, absolutamente. recipientes de IoC estão no gancho para fazer o máximo de trabalho 'criacional', como você pode se beneficiar de deixá-los lidar com eles. E o abstraaction criacional mais comum ao longo explícita novo é o Sr. fábrica.

Damon