Estava lendo sobre esses 2 Patterns e pelo que eu entendi (que provavelmente está errado) a função dos dois são iguais ou parecidas.
Alguem poderia me explicar se existe diferença?
Obrigado
Marcos,
Business Delegate provê uma abstração para o cliente usar serviços de um servidor. Ele apenas invoca um método e o BD faz todo o necessário para localizar e executar o serviço de maneira transparente.
Façade é um padrão GoF onde uma quantidade X de componentes disponibiliza seus serviços através de um ponto único, uma classe que chama os serviços das outras.
Existem comparações onde o BD é visto como um Façade do cliente. Os dois podem ser usados conjuntamente sem problemas.
[]s
Marcos,
para entender melhor esses dois patterns, pense assim:
Você implementou a camada business com EJB (Session Bean), que acessará diversos serviços para executar o negócio. É o ponto de entrada do negócio! Entao temos aí então o pattern Facade (ou conhecido ainda, nesse caso em específico com EJB-SessionBean, como Session Facade).
Agora pense, por ex, em um cliente WEB para esse Facade, uma Action (“algo” que faz a ponte da requisição WEB com a camada de business), interessado em executar os métodos de negocio.
A principio basta chamar o método de negócio, certo? Errado! No caso de EJB, é preciso antes invocar alguns serviços chatos (por ex Lookup JNDI para obter a Home, e daí obter a interface remota). Quer dizer entao que o cliente tem que saber como acessar a camada de negócio dependendo da tecnologia implementada (EJB, “POJO”, etc)? É aí que entra o Business Delegate, que cuida de todo esse trabalho! É ele quem vai fazer o lookup (de repente usando um Service Locator), se necessário, para preparar a execução dos métodos de negócio. Portanto a Action passa a “acessar o Business Delegate”, ao inves do Facade diretamente! Assim o cliente fica livre desse tipo de responsabilidade.
E se um dia tiver que mudar de EJB para POJO, por ex, a Action não sofre nenhum impacto! Bacana, nao?
Observacoes:
- Business Delegate nao pode conter nenhuma regra de negocio! Lembre-se de que ele fica NAO fica na camada de negocios! Business Delegate apenas faz o q tem q fazer pra acessar a camada de negocio e DELEGA/Repassa a chamada da action para o facade! Business Delegate deve implementar as mesmas interfaces do Facade para que a invocacao seja sempre transparente para a Action. É mto comum encontrar regra de negocio dentro do Business Delegate… incrivel! Perde totalmente o sentido de usá-lo.
- Cada caso é um caso. Utilize os patterns a medida que forem realmente convenientes.
Muito obrigado pelas explicações :lol:
Show de bola sua explicação.
No caso eu não estou usando EJB, apenas hibernate como camada de persistência, então acredito que vou usar apenas o Business Delegate entre a minha Action e meus modelos.
Como phillip falou, o BD pode parecer como uma facade se ela não existir na camada de negocios. É perfeitamente ok fazer isso.
Como o Gerson falou, o BD vai mais parecer uma bridge, já que simplesmente vai estar liberando o cliente dos detalhes da implementação (EJB lookup, home interfaces, etc).
Legal, vamos a uma dúvida.
Tenho uma Action que recebe uma requisição de uma página, essa Action chama um Business Delegate, seu objetivo é por exemplo retornar todos os clientes cadastrados no sistema com data superior a 01/01/2004. O BD chama um objeto de negocio, geralmente um DAO para ter esses valores. o meu DAO retornar todos os clientes em uma Collection para o BD que irá repassar para a Action para ela jogar na request e chamar a JSP, correto até aqui?
Se está tudo certo, esse meu BD (nesse caso) não está fazendo nada de mais, apenas fazendo um “vai-vem” de dados. Eu não poderia ‘tirar’ esse BD e da Action (que seria meu controller do MVC) chamar meu objeto de negócio? Ou estou “matando” algum pattern ae.