alguem poderia mes explicar como funciona este pattern?
Onde eu trabalho, o sistema pussuia uma fachada q instanciava os BOs(negocios) para serem utilizados pela interface, acontece q de um tempo pra cá, notou-se q a fachada estava ficando muito grande e com um construtor gigantesco (devido a qt de BOs). O pessoal entaum axou melhor trocar o pattern façade pelo ServiceLocator. Estamos usando spring aqui, como funcionaria o sistema entaum agora sem façade?
O sistema estava com estas camadas:
*interface
*serviceImplBO
*Façade
*BO
*DAO
E depois ficou assim: (O services chamam os BOs diretos agora, sem uso de façade)
Quanto a essa “mechida” na arquitetura do sistema em que você trabalha
sente com o Arquiteto e pergunte o que foi feito que você tem interesse em
saber como as coisas estão funcionando “por baixo dos panos” agora…
Só ele vai saber responder a tua pergunta corretamente…
A quantidade de BOs é alta porque eles não deveriam existir. ServiceLocators não fazem tanto sentido se você não usa EJBs. O que você descreveu não são camadas, são padrões e pseudo-padroes de projeto.
Essa arqutietura está implorando para ser refatorada.
li o artigo q vc me indicou, axei bem interessante (mesmo problema que o meu), mas o autor apenas critica uma posição, ele não sugere nenhuma forma de resolver o problema… vc diz em refatorar a arquitetura do sistema… como vc faria isso? Como resolver este problema?
Eu nao posso usar um ServiceLocator, “em um sistema que nao usa EJB”, para prover uma forma de encontrar objetos, que serao nconfigurados pelo usuario na hora da instalacao por exemplo? Poderia ate usar um ServiceLocator para eu encontrar repositorios…
“La vai o Shoes mais uma vez fala que tudo que eu pensei que tinha aprendido esta errado, ja estou ficando traumatizado!”
Porque provavelmente você se dará melhor com uma Factory que instancia as dependências e as injeta no objeto ou utilizando IoC. Mesmo com EJBs, na verdade.
Servicelocators são ótimos para retirar completamente a testabilidade do seu código, especialmente se envolvem algum tipo de atributo ou método estático
ServiceLocator é um Registry da Sun (como DAo é um DataMapper e TO um DTO).
Ao utilizar Registry uma classe de negócios X fica dependende deste para obtêr referências a outros objetos.
Uma Factory cria o objeto com toda a sua invariante preenchida. Se apra ter esta condição um objeto X precisa de um objeto Y a factory deve providenciar esta referencia, seja utilizando uma outra factory ou algo como um MRegistry, e injetá-la no objeto.