Estou começando a desenvolver um projeto, cheguei a conclusão em trabalhar em cima dessa arquitetura, mas estou com receio em algumas partes, como nos facades, já ouvi pessoas falarem quem não pode haver regras de negócios nos facades, e os DAO's apenas agem como contato da aplicação com o banco de dados. Minha principal dúvida é, terá que existir uma outra camada entre o Facades e os DAO's? ou posso colocar as regras de negócio dentro dos Facades?
Espeficicação: JPA(hibernate),Postgres,JSF
Diagrama
depende...
Enviado por Célio Vasconcel... em qua, 06/25/2008 - 11:20.E ae cara... 100%?
Pode ser que ao final da minha ajuda vc pense: E dai? Mas vamos lá...
Falando de aplicações entreprise o façade serve para proteger os CMP's (Entity Bean) do acesso remoto dos clientes. Ou seja, é a parte publicada de sua aplicação com instruções para a operação de dados em cima de regras de negócio. Também o façade é um bom lugar para adicionar segurança (controle de acesso), gerenciada pelo container ou não.
O façade dever ser um stateless ou statefull session bean. E pode receber a injeção do contexto de persistência com gerenciamento de referência no ambiente clusterizado. O façade também deve fornecer assinaturas de métodos legíveis de alto nível para o cliente, camuflando a complexidade do sistema.
Até então não falamos de regras de negócio, mas já falamos de algumas responsabilidades "atuais" do façade.
Se você achar que é uma sobrecarga de responsabilidades para essa camada adicionar a ela regras de negócio... crie outra camada somente para regras de negócio.
Isso é bom pq o facede vai conter o fluxo de chamadas aos objetos de negócio, que seriam mais coesos com menos dependências a outro objetos de negócio. O façade se tornaria um bom local para a utilização de BPM.
Uma desvantagem é que em 90% dos casos o façade será só um método burro de delegação.
Espero ter ajudado... me adiciona no Gtalk... celiovasconcelos@gmail.com
Isso dá muito mais conversa boa... vou tentar te passar umas referências... obrigado!
50 % resolvido :P
Enviado por elielsonfs em qua, 06/25/2008 - 13:08.Célio, pensei no "E daí!" mas você realmente está resolvendo minhas dúvidas.
O problema é que eu acho que não compensa ter os facades burros. A maioria deles vão ser apenas referências ao DAO, e fazer outra camada também não vai fazer muito sentido.
Mas por exemplo eu tenho uma classe UsuarioFacade, UsuarioBO, UsuarioDAO.
Vamos supor que vai validar o login o UsuarioFacade tem uma condição que verifica se já tem login(validando o acesso) e o UsuarioBO tem um método que criptografa a senha que vai ser comparada no banco e manda a senha criptografada para o UsuarioDAO fazer a busca no banco de dados.
Seria mais ou menos seguindo essa arquitetura???
vou te adicionar :P
__________________________________________________________________________
Elielson Ferreira da Silva
Isso mesmo...
Enviado por Célio Vasconcel... em sex, 06/27/2008 - 14:29.Se você criar a camada de façade + a camada de negócio separadas... seu sistema ficará mais escalar, no entanto um pouco mais inchado... é o preço que se paga por uma arquitetura enterprise.
Tudo é discutivel... inclusive o famoso old school DAO...
É muito comum, por exemplo, você utilizar o DAO completo com fábrica abstrata (o mais preventivo) e nunca colher os benfícios da adoção de tal pattern... assim como façade + bussines layer...
Se um dia pra você estiver 100% resolvido... me dá dessa água que você toma... pq nunca estará...
Floes!!
está um pouco confuso
Enviado por jrodolfo em ter, 06/24/2008 - 11:25.Eu não sei se eu entendi direito, mas parece que você está confundindo a factory com o façade. mas de qualquer forma, dê uma estudada no spring framework, utiliza-lo para gerenciar seu meio de campo entre JPA e JSF vai te trazer muitos benefícios e ainda vai te dar uma luz e te mostrar aonde colocar suas regras de negócio.