To aqui pesquisando sobre os patterns Facade e BO e surgiram várias dúvidas:
BO é a classe que contem as regras de negócio, correto?
o Facade seria uma implementação ‘simplificada’ de vários BO?
Ex.: Tenho um home theater e cada aparelho do home theater tem seus métodos especifícos ( TV - ligarTV(), desligarTV(); DVD - ligarDvd(); desligarDvd() e etc ). Para assistir usar o home theater, eu ia precisar chamar cada metodo de cada aparelho. E o Facade entra justamente para resolver esse problema: eu crio uma interface que vai ter um metodo ligarHomeTheater() e dentro desse metodo eu chamo todos os outros métodos necessários e no meu Controller, eu chamaria Facade.ligarHomeTheater().
Aew…
oque eu entendo por facade
para mim facade é uma interface que visa simplificar uma implementação
imagine em um sistema de locadora (é locadora denovo!) e bem bobão msm.
duas classes midia e fornecedor
vc pode criar uma classe intermediaria com um metodo cadastrarMidia(String nome ,String genero, String fornecedor )
CUIDADO COM OO
E BO Objetos que estão relacionados à camada de negócio da aplicação…
ha… o Pattern Delegate faz a ligação do cliente com as regras de negócio, além de não expor essas regras para o cliente!!
ele nao pode conter regra de negocio o papel dele é delegar funções acho que no seu caso escolher o melhor facade para delegar a requisição do cliente
favor me corrigam se eu estiver errado!!
Seu conceito sobre Facade está correto. Como o nome já diz, ele faz uma fachada entre o cliente e os objetos de negócio. O cliente não precisa conhecer todos os objetos de negócios, ele apenas chamada a fachada.
Sobre delegate o amigo já explicou legal. Ele é responsável por delegar a chamada de um certo método para outro método (em outro objeto), assim os métodos de negócio não são expostos diretamente para o cliente. Isso foi/é muito utilizado quando trabalhamos com EJB2 (inclusive existe o padrão Business Delegate), onde para o cliente chamar um componente EJB2, ele precisa fazer uma chamada JNDI. Para abstrair isso, e evitar acoplamento entre cliente e objetos de negócios, cria-se uma camada de Business Delegate, onde ela irá ser responsável por fazer essa chamada (delegação).
Legal, mas agora pintou algumas dúvidas. Se o Delegate faz a chamada do cliente para as classes de negócio, onde entra o Facade? Esse não seria o papel do Facade?
No caso de uma arquitetura MVC, existe ainda o Delegate e o Facade?
Partindo do JSF, existe o MBean que seria a minha classe ‘controller’.
Partindo de uma visão macro, ficaria:
Camada de Apresentacao|Camada Controladora|Camada de Negocio|Camada de Persistencia|Camada de Dados
Essa | seria o que permite a interação entre as camadas.
Para entenderem minha dúvida, eu visualiza essa arquitetura da seguinte maneira:
Camada de apresentação: seria a parte das jsp, xhtml…a view em si.
Camada Controladora: controller…parte de controle entre a view e a classe de negocio
Camada de Negocios: model …seria a parte onde ficariam os BO.
Pelo meu entendimento, aqui se fecha o padrão MVC. Acho que na Camada de Negocios, entrariam os Facades, correto?
Camada de Persistencia: DAO
Camada de Dados: BD
Ainda não consigo visualizar um Delegate ai no meio :S
Acredito que você ainda esteja confundindo as coisas :lol: . O Delegate vai delegar uma chamada para outra classe/método. Pode até ser 1 para 1, ou seja, o Cliente chama 1 método e o Delegate delega para apenas 1 método da outra classe, bem simples. Mas a pergunta fica: porque usar Delegate então? Usa-se ele quando a chamada para o outro método não é tão simples, onde existem fatores que irão acoplar as camadas (e isso não é bom). Um exemplo é chamada JNDI do EJB2
O Facade é para fazer uma fachada entre o cliente e vários outros objetos. O Cliente não precisa saber da existência de todos os objetos do domínio, apenas da fachada… Um exemplo que eu li a um tempo atrás e gostei muito foi do computador. Quando vamos ligar o computador, simplesmente apertamos o botão de ligar e internamente ocorre vários processos (memória, HD, monitor e etc). Portanto, o computador poderia ser uma fachada e memória, hd, monitor poderiam ser classes do dominio. Mas para ligarmos o computador, simplesmente chamamo o método computador.ligar() que irá ser responsável por chamar os outros métodos dos outros objetos. (isso é uma fachada). Nós (clientes) não temos conhecimento dos outros objetos do domínio.
Sobre como juntar esses caras em uma arquitetura é algo um pouco mais delicado. A primeira e importante dica é: só use os padrões de projetos se eles realmente se aplicam a sua necessidade. Não vá querer enfiar um monte de camadas a mais só para dizer que está bonitinho. Quanto mais simples, melhor. Portanto, se na sua arquiteura o MVC padrão (V = JSP, C = Servlet, M = modelos) satisfaz seus requisitos, ótimo, fique no mais simples.
Agora usando o seu exemplo, imagine que sua camada de negócio esteja em um módulo EJB2 e sua aplicação tem que chamar esse EJB2, o que fazer? Chamar o Delegate… porém, sua funcionalidade exige que vários objetos sejam invocados (exemplo de ligar o computador), então vamos usar o facade… No final, ficaria mais ou menos assim:
Camada de apresentação: seria a parte das jsp, xhtml…a view em si.
Camada Controladora: controller…parte de controle entre a view e o Delegate
Delegate: Faz a chamada JNDI para um Session Bean. Porém, vamos usar vários SessionBeans, então é melhor delegar para um Facade
Facade (ou Session Facade do J2EE): Irá invocar todos os outros SessionBeans e completar o request
Camada de Negocios: Seus componentes EJB.
Espero que fique mais claro. E lembre-se: simplicidade
Camada de apresentação: seria a parte das jsp, xhtml…a view em si.
Camada Controladora: controller…parte de controle entre a view e o Delegate
Delegate: Faz a chamada JNDI para um Session Bean. Porém, vamos usar vários SessionBeans, então é melhor delegar para um Facade
Facade (ou Session Facade do J2EE): Irá invocar todos os outros SessionBeans e completar o request
Camada de Negocios: Seus componentes EJB.[/quote]
Mas como seria essa camada controladora?
Onde eu crio o delegate? No pacote war? Ou crio um pacote intermediário entre a view e o negócio, contendo o delegate e o façade?
[quote=davidpadilha]To aqui pesquisando sobre os patterns Facade e BO e surgiram várias dúvidas:
BO é a classe que contem as regras de negócio, correto?
o Facade seria uma implementação ‘simplificada’ de vários BO?
Ex.: Tenho um home theater e cada aparelho do home theater tem seus métodos especifícos ( TV - ligarTV(), desligarTV(); DVD - ligarDvd(); desligarDvd() e etc ). Para assistir usar o home theater, eu ia precisar chamar cada metodo de cada aparelho. E o Facade entra justamente para resolver esse problema: eu crio uma interface que vai ter um metodo ligarHomeTheater() e dentro desse metodo eu chamo todos os outros métodos necessários e no meu Controller, eu chamaria Facade.ligarHomeTheater().
To correto?
[/quote]
Sim.
Um delegate (Emissário/Procurador) é um cara que pode atuar como o proprio BO só que em outro lugar.
O delegate recebe aval (uma procuração por assim dizer) do BO para agir em seu nome. (como os advogados agem em nome dos seus clientes)
So que eles não sabem decidir , por isso eles têm que acabar delegando (dai o nome) para o objeto real.
Na prática Delegator só é usado quando vc tem muitas máquinas e o BO está no servidor. O Delegator - que está no cliente - tem que encontrar o BO (via EJB ou outro metodo - ServiceLocator) e executar uma chamada remota a ele ao objeto real.
Isto tb se aplica, por exemplo quando vc usa um webservice. O seu cliente de webservice que faz a invocação nada mais é que um delegate.
O nome canónico do padrão é Business Delegate ( Emissário/Procurador de Negocio)
Pro exemplo de Façade uso mais um controle remoto universal.
Você quer ligar a TV, o Home Theater, e o aparelho da TV a cabo, e vários aparelhos. Dá um trabalho ficar com um monte de controle na mão. Daí você compra/monta um controle universal que funcione com todos. Ele é o teu Façade.
[quote=Bruno Laturner]Pro exemplo de Façade uso mais um controle remoto universal.
Você quer ligar a TV, o Home Theater, e o aparelho da TV a cabo, e vários aparelhos. Dá um trabalho ficar com um monte de controle na mão. Daí você compra/monta um controle universal que funcione com todos. Ele é o teu Façade.[/quote]
Bruno, esse é o exemplo do Head First, né? É um os melhores possíveis, muito bem lembrado.
Eu geralmente faço Façades pra fazer a comunicação de uma Controladora com os DAOs.
Então fica parecido com isso:
Model <- Controladora <-> FaçadeAlgumaCoisa <-> DAOs
Está incorreto ou incoeso (essa palavra existe?) fazer assim?
[quote=Andre Brito][quote=Bruno Laturner]Pro exemplo de Façade uso mais um controle remoto universal.
Você quer ligar a TV, o Home Theater, e o aparelho da TV a cabo, e vários aparelhos. Dá um trabalho ficar com um monte de controle na mão. Daí você compra/monta um controle universal que funcione com todos. Ele é o teu Façade.[/quote]
Bruno, esse é o exemplo do Head First, né? É um os melhores possíveis, muito bem lembrado.[/quote]
Lembrei agora de um exemplo que utiliza Delegate junto com Facade.
Na época do EJB 2.x, utilizava um delegate para acesso ao EJB REMOTO, por sua vez, esse EJB era um Facade, que chamava os BO (EJB’s LOCAIS).
Isso para ganhar perfomance, vc só fazia uma chamada remota.
Essa abordagem ainda é muito utilizada, porém sem a necessidade do delegate, uma vez que agora utilizo Annotaion + Injeção de Dependencia.
