O StaticFactory no codecampServer é um padrão bem conhecido?

Question

O código -fonte codecampServer contém um genérico StaticFactory.

Estou supondo que esta é uma peça essencial do mecanismo de como a estrutura é bem com a injeção de dependência.

As subclasses de que usam seu DefaultunconfiguredState para fornecer acesso estático a, bem, um estado não conferido padrão para si mesmo que o mecanismo de resolução de dependência pode substituir pelo material de trabalho.

Não consegui encontrar nenhuma documentação para isso ...

Existe uma boa explicação em o livro? (Estou aguardando entrega da Amazon ...)

... ou alguém pode fornecer um bom comentário sobre o que é isso e se eu seria aconselhável adotar esse padrão (se for um ...)?

Atualizar

Como Jeffrey Palermo respondeu a essa pergunta, vejo que no manuscrito (em andamento) para MVC2 em ação, esse padrão/estilo é discutido e ilustrado usando uma fábrica que é usada para localizar um repositório para manter a camada de domínio ignorante de preocupações de persistência. (Vejo Capítulo 23).

Por padrão, o uso desta fábrica lança uma exceção:

"O conhecimento de como criar o repositório não reside com a fábrica. Essa fábrica apenas representa a capacidade de devolver o repositório"

O exemplo poderia ter usado um dos vários mecanismos para inicializar uma implementação concreta da interface do repositório. No exemplo, no livro, eles optam por não usar um contêiner do COI por causa da simplicidade e fornece-o explicitamente em alguma lógica de inicialização.

"O importante é que nem o projeto principal nem o projeto da interface do usuário devem referenciar o projeto de infraestrutura ou bibliotecas que são de natureza puramente infraestrutura O acesso a dados está acontecendo "

Um ponto final a ser observado sobre o código de exemplo neste novo capítulo é que a fábrica não é mais estática (pelo menos não no que diz respeito à interface voltada para a frente).

Atualização 2

O Sr. Palermo escreveu um pouco mais sobre Este estilo específico de fábrica abstrata (Veja a implementação do OrderShipperFactory).

Eu também poderia Basta considerar a 'injeção de dependência manual' (Tio Bob).

Atualização 3 - março de 2016

Há Outro exemplo disso aqui, embora Jeffrey seja explícito sobre esse código de demonstração, e o comentário indica que isso seria configurado no que Mark Seeman chamaria de um Raiz de composição (ou seja, na inicialização do aplicativo)

Eu descobri isso no artigo de Jeffrey "Arquitetura de cebola: Parte 4 - após quatro anos"

Answer 1

Boa pergunta. Eu também não gosto disso. Ele deve realmente ser nomeado "StartupFactoryConfiguration", mas está na lista de refatores.

Nós brincamos com essa idéia como uma maneira de configurar DI para lugares que não estavam sob injeção de construtor através do contêiner.

Vai desaparecer. Não sei o que é o anti-padre (que nome?), Mas o StaticFactory morrerá.

---

Agora foi renomeado até esta manhã. Agora é abstratafactoryBase. É uma implementação do padrão de fábrica abstrato: http://en.wikipedia.org/wiki/abstract_factory_pattern

A implementação da fábrica é acabar chamando de contra -contrato do COI, mas permite o acesso de um local no código sem uma referência de montagem ao conjunto do contêiner do COI.

Atenciosamente, Jeffrey Palermo

Answer 2

Qualquer coisa estática é um inimigo de DI.

Este staticfactory parece uma implementação do Localizador de serviço (Anti-) padrão.

Considero que o localizador de serviço é um anti-padronização, pois é totalmente opaco para o usuário da API que as dependências precisam estar em vigor; Assim, pode -se facilmente invocar métodos em objetos em um contexto em que o localizador de serviços lançaria, e a API não lhe dá absolutamente nenhuma pista de que esse é o caso.

DI adequado, como uso abundante de Injeção de construtor é uma alternativa muito melhor.