Desing Patter Business Delegate E Facade

Bom dia rogeriosantos77.

Pelo que sei, o Business Delegate é aplicada no cliente, já o Facade é um padrão da camada de negócios. Nada impede de você utilizar os dois padrões de projeto.

Até Mais,
Matheus

Façade, Observer, Decorator e a maioria dos padrões GoF são mais “genéricos”, eles podem ser utilizados em qualquer lugar. Seu Business Delegate pode, na verdade, ser implementado usando um Façade.

Então amigos, li os links entrentanto algumas duvidas pairam sobre mim ainda. Eu que eu percebo é que existe uam certa diferença na especificação do padrão e o que realmente é aplicado na vida real.
Vou expor a situação que me fez rever meus conceitos sobre o business delegate e o facade. gostaria da critica de vcs.

estiou em um projeto que esta assim.

A camada visual é JSF então o managed bean instancia uma classe Business Delegate. Dentro desse business Delegate existe uma chamada para um facade e este facade chama uma classe de negocio (BO), que contem toda a regra do negocio.
No meu ponto de vista a ligação entre a comada de negocio (a clase BO) e a camada visual o Manage Bean (jsf) deveria ser feita somente pelo facade, descartando assim a existencia do business delegate.
Entretanto um outro desenvolvedor contestou as duas estruturas sugerindo uma terceira estrutura , dizendo que o correto seria a criação de um facade que chamaria um business delegate e este por sua vez chamaria a classe ou as classes de negocio.
Confesso que achei interessante a terceira sugestão afinal acredito que o elo de ligação entre a camada visual e as demias camadas deve ser feita via facade, sendo que o business delegate encapsularia a chamada aos objetos de negocio, dando a opção de se ter a flexibilidade de trocar a regra caso necessário fazendo a alteração noi business delegate somente.

O que vcs acham ? alguima colocação que eu postei aqui faz sentido ? vendo estes cenários o que vcs poderiam fazer de critica ou sugestão ?

É bom lembrar que não existe “o correto” neste caso, existem opções que sempre trazem vantagens e desvantagens.

De qualquer forma, por que vocês estão utilizando um Business Delegate em primeiro lugar? Você já de uma lida nas forças para o uso deste padrão?

Sua dúvida me deu a impressão de que vocês não estão utilizando o padrão numa real necessidade. Um Business Delegate é uma Façade no lado do cliente que geralmente acessa outra Façade no lado do serviço utilizado. O grande objetivo do BD é esconder do cliente toda a parafernalha necessária para chamar um serviço.

Como um exemplo, suponha que você tenha uma aplicação web que acessa um serviço em outro servidor usando HTTP e XML. Suponha que para invocar aquele serviço você precise de algo assim:

public void procurarPorCarro(Vaga v){

   Carro c;
   String mensagemEmXml = =constroiRequisicaoPara(v.getId(), TRANSPORTE.NAO_TRANSACIONAL, false, false); 
   URL servico = new URL("http://www.meuservico.com/");
        URLConnection conexao = servico.openConnection();
        BufferedWriter bf = //...
        bf.write(mensagemEmXml);
        conexao.close();
        //blablabla de HTTP
          
     c = converteMensagemXml(resposta);   

  request.setAttribute("carro", c);
   redirecionaParaAlgumLugar();
}

É claro que você poderia apenas extrair o codigo da conexao para um metodo e reutiliza-lo sempre mas isso nao resolve o fato de que o cliente (a webapp) sabe todas as esquisitices que sao necessarias para conectar ao servidor. O que precisamos eh de um Façade (que esconde esquisitices) para o cliente, logo um Business Delegate.

public void procurarPorCarro(Vaga v){
   Carro c = servicoDeLocalizacao.carroNaVaga(v);   
  request.setAttribute("carro", c);
   redirecionaParaAlgumLugar();
}

Meu questionamento no seu caso se deve ao fato de que eu acredito que você sequer tem estes problemas, logo não faz muito sentido tentar solucioná-los (uma solução para um problema inexistente acaba virando um problema por si só).

Sobre o BO, vou assumir que você quis dizer “um objeto de negócios”, se você na verdade está se referindo ao pseudo-padrão BO/VO eu acho que você tem problemas maiores para se preocupar

Valeu pcalcado, realmente o que vc colocou faz muito sentido pra mim e deu um clareada legal.
Acredito mesmo que não estamos tendo uma necessidade de um BD.

PS : Realmente o BO é o Objeto de negócio.

antigamente o Business Delegate era fortemente recomendado com o uso do Service Locator, mas com adoções de práticas de IoC você consegue bastante flexibilidade e menos acoplamento, de forma declarativa por exemplo, como no exemplo do philip acima ou obtendo algum recurso através de JNDI.

rogeriosantos77:

O Business Delegate e o Pattern Facade seriam a mesma solução ?
Uma vez que o facade esconde a implementação de um método sendo a porta de entrada para um metodo, o Business Delegade faria o mesmo correto ? afinal ele esconde a implementação de um metodo sendo tambem uma porta de entrada para execução do mesmo.
Ou seriam coisas totalmente diferentes e eu estou equivocado ?

Não muito. O Façade é um padrão genérico que unifica em uma invocação muitas outras invocações. É um padrão para diminuir invocações, código e simplificar o uso de alguma API. A sua função principal não é desacoplamento embora isso possa decorrer naturalmente. Um objeto façade é chamado “na frente” (fachada) de outros.

O Business Delegate é um padrão JEE e funciona como um agente destacado. É um objeto que conhece o negocio mas não está no servidor.
Ele sabe como e o quê delegar ao servidor. Ele está mais para Mediator, mas do ponto de vista do cliente ele parece um Façade por
também fica 'na frente" do servidor.

O Façade é genérico, o Business Delegate é particular da arquitetura JEE e normalmente faz burucráticos relacionados à comunicação com o servidor e não apenas invocar métodos de negocio. Ele é baeado no Façade mas tem lago a mais.
Não é totalmente correto dizer que um Business Delegate é um Façade, mas também não é correto dizer que não é.
São dois padrões de “mundos” diferentes. Então eles estão relacionados conceptualmente, embora não tenham nada em comum na hora de implementar.