verifica��o de formato (que independem de l�gica de neg�cio) pode e deve ser feita no cliente (e talvez validada novamennte no servidor) , vc deve fazer chamadas ao business delegate apenas quando precisar executar alguma l�gica de neg�cio.
Maykel Tres wrote: > Ola pessoal, > > eu estive acompanhando a discuss�o sobre business delegator e com isso > surgiu uma d�vida cruel. > > eu utilizarei o BD para que caso mude meu back-end eu n�o precise > alterar nada no meu cliente. Minha pergunta segue esse racioc�nio. > > Eu devo colocar todo o processamento no servidor? Desde verificar > se algum dado � daquela forma ou n�o? > > agrade�o colabora��o, > > Maykel > > ----- Original Message ----- > From: Ale! <mailto:[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > Sent: Thursday, October 03, 2002 12:17 PM > Subject: Re: [enterprise-list] Business Delegator > > Eu discordo. > > Cliente ------>WebserviceClient Impl------->SOAP----> JAX-RPC > webservice endpoint -----> BusinessDelegate1 ------> SessionBean > ------> EntityBean > Exemplificar com esse n�vel de detalhe n�o iria acrescentar nada aos > objetivos do exemplo. Al�m do mais, fazendo como vc fez o cliente t� > todo amarrado no WebserviceClient Impl. E se por acaso ele quisesse > retirar essa casca WebService e voltar a utilizar EJB diretamente ? > Teria que alterar TODOS os clientes, que � justamente o que n�o se > deseja fazer. > > Por mim, para atingir os objetivos do Business Delegate, deveria ser: > > Cliente ------> BusinessDelegate1 ------> WebserviceClient > Impl------->SOAP----> JAX-RPC webservice endpoint -----> SessionBean > ------> EntityBean > > Quanto a outra parte, pres'ten��o na preocupa��o de quem fez a pergunta > > "A ideia � utiliza-lo para mais tarde migrar a aplica��o para a > plataforma J2EE com EJB e assim evitando mudan�as na parte do cliente" > > Ele n�o quer utilizar o BD para evitar altera��es na camada neg�cio > quando a camada cliente muda, como vc fez. Ele quer evitar alterar o > cliente quando a camada de neg�cios sofrer altera��es. > > A abordagem que vc fez � a de que o BD seja um simples proxy do > Session, quando eu acho que ele deveria ser algo mais. Ser apenas um > proxy � papel de um Client Facade. IHMO, Business Delegate = Client > Facade + Service Locator > > Veja o que diz a documenta��o do BD: " Potentially, this (Business > Delegate) reduces the number of changes that must be made to the > presentation-tier client code when the business service API or its > underlying implementation changes." (from > http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html) > > []s > By Ale! > > > ----- Original Message ----- > From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > Sent: Thursday, October 03, 2002 7:26 AM > Subject: Re: [enterprise-list] Business Delegator > > > > > Cliente ------> BusinessDelegate1 ------> SessionBean ------> > EntityBean > > > > Toda a complexidade envolvida na manipula��o de EJBs fica > concentrada no BD. > > Se por acaso, a tecnologia mudar para WebServices, teremos > que fazer as > > mudan�as apenas no BD, mantendo sua interface de servi�os e, por > > consequ�ncia, mantendo a implementa��o do cliente intacta. > > > > Cliente ------> BusinessDelegate2 ------> WebServices --> > > SessionBean ------> EntityBean > > At� ae tudo bem, mas aqui est� enganado. Seria: > Cliente ------>WebserviceClient Impl------->SOAP----> JAX-RPC > webservice endpoint -----> BusinessDelegate1 ------> SessionBean > ------> EntityBean > > O objetivo � esconder a complexidade de EJB para o cliente e > separa��o de camada de apresenta��o da camada de negocios > (loosely coupled). O Business delegate neste sentido � um proxy. > Do seu jeito n�o faz sentido nenhum pois em qq tipo cliente > deveria ser implementada um outro Business Delegate. A proposta > do business delegate �: > WebCliente ------> BusinessDelegate1 ------> SessionBean ------> > EntityBean > PDACliente ------> BusinessDelegate1 ------> SessionBean ------> > EntityBean > WebServiceCliente ------> BusinessDelegate1 ------> SessionBean > ------> EntityBean > SWINGCliente ------> BusinessDelegate1 ------> SessionBean > ------> EntityBean > VBJCommCliente ------> BusinessDelegate1 ------> SessionBean > ------> EntityBean > DelphiJCommCliente ------> BusinessDelegate1 ------> SessionBean > ------> EntityBean > WAPCliente ------> BusinessDelegate1 ------> SessionBean ------> > EntityBean > > > > Uma estrat�gia que eu acho legal � agrupar casos de uso > semanticamente > > relacionados em Session Facades que disponibilizam servi�os > de alto n�vel de > > abstra��o e utilizar o Business Delegate como Client Fa�ade > para funcionar > > como um proxy do Session Fa�ade no lado cliente. > > Quase. O Business Delagate � o ponto de entrada (proxy) de > componentes. > > > > > > []s > > By Ale! > > > > ----- Original Message ----- > > From: "F�bio Barboza de Oliveira" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Wednesday, October 02, 2002 10:32 AM > > Subject: Re: [enterprise-list] Business Delegator > > > > > > Mas acho improv�vel que n�o seja necess�rio reescrever os > clientes, pois a > > maneira com se faz acesso aos EJBs (Entity, session) � algo > mais complexo. > > Acredito que se as classes fossem modelas de forma bem > semelhante ao modelo > > do EJBs, ai sim as altera��es para os clientes seriam pequenas. > > No EJB, voc� tem o metodos Home, para criar (ejbCreate) no > caso de um Entity > > Beans ele ser� respos�vel pela cria��o de um novo registro na > base, etc... > > E > > tem os m�todos de negocio que ficam na interface. > > Se voc� modelar as classes de maneira diferente, tipo criar > uma classe que > > tenha um m�todo "inserirUsuario" ou "consultarUsuario", essa > classe estar� > > longe de parecer com um EJB, sendo assim seu cliente ter� que > ser reescrito > > tambem. Pode-se at� criar um Bean dessa maneira, mas voc� > estar� fugindo do > > padr�o EJB e podendo comprometer a performance do Aplication > Server. > > N�o concorda? > > > > > > Em Qua 02 Out 2002 09:58, Bruno Copelli escreveu: > > > Bom dia Fabio. > > > > > > Utilizando os Business Delegates vc pelo menos nao vai > precisar reescrever > > > a parte cliente qndo fizer a migracao. So vai precisar > reescrever o > > > conteudo dos delegates. Eu pelo menos apostei nessa estrategia. > > > > > > Abracos, > > > > > > Bruno > > > > > > ----- Original Message ----- > > > From: "F�bio Barboza de Oliveira" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Wednesday, October 02, 2002 9:51 AM > > > Subject: [enterprise-list] Business Delegator > > > > > > > > > Caros colegas, > > > > > > Gostaria da opni�o de voc�s sobre a utiliza��o de um > Business Delegator > > > para o desenvolvimento de um sistema java. > > > A ideia � utiliza-lo para mais tarde migrar a aplica��o > para a plataforma > > > J2EE com EJB e assim evitando mudan�as na parte do cliente > Swing. > > > Eu queria saber se vale a pena utilizar um Business > Delegator ou ele ser� > > > uma > > > perda de tempo pois a aplica��o ter� que ser reescrita para > a plataforma > > > J2EE > > > mais tarde tando na parte de clientes quanto na parte do > servidor, pois a > > > modelagem n�o est� seguindo a metodologia EJB. > > > > > > Atenciosamente > > > > > > F�bio Barboza de Oliveira > > > > > > > --------------------------------------------------------------------- > > > Para cancelar a subscri��o, envie mensagem para: > > > [EMAIL PROTECTED] > > > Para comandos adicionais, envie mensagem para: > > > [EMAIL PROTECTED] > > > > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.393 / Virus Database: 223 - Release Date: > 30/9/2002 > > > > > > > _______________________________________________________________________ > > > Yahoo! Encontros > > > O lugar certo para encontrar a sua alma g�mea. > > > http://br.encontros.yahoo.com/ > > > > > > > --------------------------------------------------------------------- > > > Para cancelar a subscri��o, envie mensagem para: > > > [EMAIL PROTECTED] Para comandos > adicionais, envie > > > mensagem para: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > Para cancelar a subscri��o, envie mensagem para: > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > Para cancelar a subscri��o, envie mensagem para: enterprise-list- > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: enterprise-list- > > [EMAIL PROTECTED] > -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959 | | SICREDI Servi�os | | Porto Alegre - Brasil | |xxxxxxxxxxxxxxxxxxxxxxxxxx| --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
