Pessoal o que seria o padrão facade, um ejb é um facade?
Em um padrão de arquitetura dividida em
DAO (acesso dados)
BO(logica de negocio - EJB)
MB(controlador)
jsf(.xhtm)
aonde fica o facade?
facade, seria o cara que fica entre a camada de apresentação e a camada de negocio, ele “monta” como a estrutura vai ser executada
faz a injeções necessárias de DAO´s e Services, isso serve para “desacoplar” a camada de negocio da camada de apresentação, um existe independente do outro… não sei se ajudei ou compliquei mais hehe.
Não misture facade com controller…
A tradução literal de Facade é Fachada. Isso quer dizer que ele deve atuar como uma interface (não confunda com interfaces, aquelas que são implementadas) para camadas, de maneira a simplificar casos complexos com uma única chamada. Por exemplo, uma operadora de call center é a fachada dos processos internos que ela executa para atender uma reclamação sua, por exemplo.
Isso quer dizer que a fachada pode ficar em qualquer camada na sua aplicação, não importa… só lembrando que design patterns foram feitos para facilitar a sua vida, e você deve usar onde se aplicar, OK?
[]´s
Olá, achei isso aqui da uma olhada e veja se ajuda: http://www.pg.cefetpr.br/coinf/simone/patterns/facade.php
Intedi mais o menos
Mais no facede eu injeto um BO né nao um DAO
Quando se fala em Facade, temos dois padrões a considerar: Facade clássico descrito pelo GoF e Session Facade descrito em Core J2EE Patterns.
O padrão Facade GoF descreve uma forma de reduzir a complexidade de uso e o acoplamento entre um cliente e uma API. A idéia do Facade é que ele coordene uma colaboração complexa entre diversos objetos e exponha uma interface simples para uso dessa colaboração.
Ex.:
UsinaFacade
public void abrirValvula(String codigoValvula, BigDecimal percentual) {
// instancia 30 objetos diferentes e os manipula para abir a válvula…
}
O padrão Session Facade estende a idéia do Facade para uma arquitetura JEE baseada em EJB, onde um Session Bean faz o papel de Facade para interagir com Application Services, Business Objects e DAOs. O Facade é normalmente acessado por um Business Delegate (que abstrai detalhes de acesso a EJBs) e o Business Delegate por sua vez é acessado por sua camada de Apresentação.
Então…
O façade é como se fosse uma interfacezona, onde vc esconde a implementação de um monte de classes que compõem, geralmente, regras de negócios que fazem sentido ficarem juntas. Isso pode ser para qq lugar da sua arquitetura, desde que faça sentido no seu contexto.
Por exemplo, suponha que vc está trabalhando para outra empresa e ambas precisam estabelecer um “contrato”, ou uma API para que um sistema use o outro. Uma simples classe de interface de API bem especificada é um façade.
Alguns anos atrás, eu tive que desenvolver para um cliente que tinha limitação de banda e que mantinha um banco de dados enorme que eu não tinha como replicar aqui. A solução que encontramos na época foi definir um façade que encapsulava grande parte da lógica que acessava o banco e eu tinha uma implementação dessa interface local que acessava um banco completamente diferente, mas que fornecia as mesmas funcionalidades.
Alguns dias atrás, no projeto em que estou hoje, eu precisava testar uma coisa besta numa arquitetura EJB grande e complicada, e tudo o que eu precisava era implementar uns 2 métodos do façade com alguns objetos mock para testar uma funcionalidade sem precisar ficar levantando jboss, hibernate e etc. Bastou criar uma classe implementando a interface (isto é, o façade) e mexer em poucas linhas e logo eu estava com a devida liberdade para testar a tal funcionalidade.
Outro efeito colateral interessante dos façades é que muitas vezes, quando não há tempo para documentar o código (quase sempre isso acontece…), um façade bem documentado muitas vezes resolve, especialmente em sistemas onde a lógica de negócios é mais complicada.
É para isto que servem os façades. Faça bom uso deles.
Leo K.
esmiralha não intendi os dois tipos de facade que vc falou, no final não é um só?
O padrão Facade clássico é agnóstico em relação a tecnologia. O Session Facade não. Ele especifica que você deve usar um EJB Session Bean para intermediar a colaboração complexa entre Application Services, BOs e DAOs. Como eu disse, o Session Facade especializa o padrão clássico para uma arquitetura J2EE. A intenção do padrão é quase a mesma.
Resumindo é uma classe onde vai ter todos os métodos de inserção, consulta etc. do seu projeto
Olha esse link, fala sobre padrões de projeto, entre eles o Facade
http://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwcm9mbWFyY29zbGFwYXxneDpmYjkxZmViMjY0ZTY1MDI
Uma classe com todos os métodos do seu projeto vai ser um monstro. Divida seu projeto em componentes e crie um Facade para cada componente.
Eu trabalho deste jeito
DAOs — (persistencia (JPA + HIBERNATE))
BO — (classes de negocio insert . delete , etc etc aqui eu instacio o DAOs)
MBs ---- controles (inset delete etc etcc aqui eu instacio um BO)
EX: bo.inset que por sua vez dao.insert e assim vai…
pelo que eu li o pessoal costuma criar um facade entre o BOs e MBs,
DAOs — (persistencia (JPA + HIBERNATE))
BO — (classes de negocio insert . delete , etc etc aqui eu instacio o DAOs)
FACADE – (instacia um BO e faz insert, delete)
MBs ---- controles (instacia um FACADE etc etc)
Pra que isso ? se um dia eu mudar de JSF MB para Flex no flex eu vou temque criar mesma coisa os metodos que meu MB tinham E VOU CHAMAR O FACADE, mais se eu nao tiver o facade eu chamo o BO, daria na mesma…
Uma das vantagens de um Facade é promover o desacoplamento entre o cliente e a API subjacente. Se para realizar determinada tarefa, você tem que usar 4 objetos diferentes, é interessante esconder essa complexidade atrás de uma Facade para facilitar uma eventual troca do cliente, porque ao invés de estar acoplado a 4 classes ele enxerga apenas a Fachada (Facade).