Ae galera ja andei dando umas lidas sobre isso mas, queria uma explicação legalzinha de vcs… tipo tanto em def. como se poder em um ex. (ñ é obrigado dar os 2 :D)
Agradeço.
Ae galera ja andei dando umas lidas sobre isso mas, queria uma explicação legalzinha de vcs… tipo tanto em def. como se poder em um ex. (ñ é obrigado dar os 2 :D)
Agradeço.
Session Façade (tem cedilha sim, a palavra vem do francês):
Eh uma “Fachada”, um seja, uma classe (geralmente um SessionBean) que possui um método (por exemplo transferir X Reais da Conta A para a Conta B), e nesse método movimenta vários objetos e vários métodos (obtem os dados da conta A, verifica se tem saldo disponivel, obtem os dados da conta B, tira de A e Poe em B). Com isso vc pode ter uma transação no método todo da fachada (transefirDinheiro), assim, se ocorrer algum problema, nada será feito. E a interface do seu componente fica mais simples pq só tem um método (no exemplo de transferencia)
Ficou claro!?
da uma olhada nesses 2 links, ótimas referênias:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
blz meu fi… agora melhorou
e o Delegate la? alguem ajuda
Delegate é simples.
Velho exemplo do cadastro de usuário:
vc teria um Delegate para o usuário assim:
public class UsuarioDelegate
{
public criarUsuario(){}
public deletarUsuario(){}
}
Com isso vc não precisa se preocupar com qual classe que faz a criação de um usuario, ou a deleção de um usuário. Tbm deminui o acoplamento das suas classes.
O Delegate se responsabiliza em se preocupar com as classes que ele precisa chamar
Acho que é isso né?! Por favor não me deixem mentir sozinho!!!
Abraços!!
e no caso do delegate, só é realmente util em uma app q tem tb camadas físicas diferentes, onde o delegate é quem se encarrega de utilizar o ServiceLocator pra pesquisar o componente na rede pra depois delegat :joia:
Não necessariamente! (eu acho) Vamos analizar esse caso:
Pode-se utilizar o Delegate simplesmente para que diminua-se o acoplamento, e outras coisas mais. Digamos que vc chame uma inserção de usuario em vários lugares do seu sistema. Agora imagine que vc mude uma assinatura de algum método. Vc teria que sair mudando em tudo que é lugar que vc usou a chamada para aquela classe. Já usando um Delegate vc apenas muda dentro do Delegate e todas as outras classes que a chamaram nem saberão qeu foi mudado.
Ahn… será que isto é válido?!
Abraços!
bem, mas o ideal não é alterar a interface publica de um negócio… a interface publica não muda, oq se pode fazer é outros métodos (privados da classe ou não) pra ajudar nesse refactoring. Eu pessoalmente só adiciono uma camada proxy qnd tem serviços na rede envolvidos…
Business Delegate é apenas uma camada a mais que vai isolar o cliente q está acessando a camada de negócio direta. Um B.D(Business Delegate está para um Session Bean). Mas um B.D pode estar se relacionando com outro B.D
Um dos grandes problemas que tornou o B.D importante nos projetos foi o forte acoplamento, o cliente deveria saber o nome do JNDI, às vezes tinham relacionamento entre os Sessions Beans, além das excecoes que são específicas de negócio.
Antes era assim:
---------> | Session Bean 1
CLIENTE ---------> | -------------------> | JNDI
---------> | Session Bean 2
agora com o B.D fica mais facil para o cliente acessar a camada de negócio.
---------> | Business Delegate1 | ---> | Session Bean 1
CLIENTE ---------> | Business Delegate2,3 | -------------------> | JNDI
---------> | Business Delegate3 | ---> | Session Bean 2
Entao para o Business Delegate encontrar os servicos que serao oferecidos para o cliente, utilza um Service Locator http://www.portaljava.com/home/modules.php?name=Content&pa=showpage&pid=4
Além disso ainda tem o Business Service, que seria o Session Facade.
O que acho legal nesse padrão , é que o mesmo torna oculta que os objetos são acessados remotamente.
Deve ser levada em conta a complexidade da aplicacao antes de utilizar esse padrão, pois vc pode adicionar uma camada a mais sem necessidade.
De todas as “mentiras” a que mais concordo é a do fmartins.
O Business Delegate usa um ServiceLocator para acessar sua camada de negócio (SessionBean).
Quanto a um BD usar outro BD eu evito de fazer isto, para mim a solução fica mais limpa quando o cliente usa um ServiceLocator para obter o Business Delegate então um BD desconheçe o outro. Mas existem alguns casos que é melhor não fugir disto e que fica até melhor se você o fizer.
Esqueça Business Delegates, use um Container IoC e seja feliz.
IoC é punk…
Você não precisa se preocupar com a bagaça, ela já está lá, prontinha para ser utilizada =P
alguem teria um bom link pra esse IoC ?
ae pessoal,
achei esse link, espero q possa ajudar pra quem tiver interesse.
[quote=“fmartins”]ae pessoal,
achei esse link, espero q possa ajudar pra quem tiver interesse.
http://martinfowler.com/articles/injection.html[/quote]
Uma versão traduzida dele aqui:
http://www.javafree.org/content/view.jf?idContent=1
valeuz…
[quote=fmartinsPJ]Business Delegate é apenas uma camada a mais que vai isolar o cliente q está acessando a camada de negócio direta. Um B.D(Business Delegate está para um Session Bean). Mas um B.D pode estar se relacionando com outro B.D
Um dos grandes problemas que tornou o B.D importante nos projetos foi o forte acoplamento, o cliente deveria saber o nome do JNDI, às vezes tinham relacionamento entre os Sessions Beans, além das excecoes que são específicas de negócio.
Antes era assim:
---------> | Session Bean 1
CLIENTE ---------> | -------------------> | JNDI
---------> | Session Bean 2
agora com o B.D fica mais facil para o cliente acessar a camada de negócio.
---------> | Business Delegate1 | ---> | Session Bean 1
CLIENTE ---------> | Business Delegate2,3 | -------------------> | JNDI
---------> | Business Delegate3 | ---> | Session Bean 2
Entao para o Business Delegate encontrar os servicos que serao oferecidos para o cliente, utilza um Service Locator http://www.portaljava.com/home/modules.php?name=Content&pa=showpage&pid=4
Além disso ainda tem o Business Service, que seria o Session Facade.
O que acho legal nesse padrão , é que o mesmo torna oculta que os objetos são acessados remotamente.
Deve ser levada em conta a complexidade da aplicacao antes de utilizar esse padrão, pois vc pode adicionar uma camada a mais sem necessidade.[/quote]
Antes de falarem eu sei que estou revivendo um tópico, mais tenho duvidas sobre isso e creio que esta thread pode me ajudar,
Como o amigo disse acima o Business Delegate faz com que o Cliente não faça um chamada JNDI, então o Business Delegate fica no jar com as interfaces que o client adiciona? então eu chamo o Business e ele me retorna o serviço? É mais ou menos isto?
Abraço, Obrigado desde já.