hummmm Eu tenho algumas considera��es: Vc n�o deveria estar acessando seus entities deireto da camada cliente. Uma boa pr�tica J2EE diz para encapsular todo acesso a entities atrav�s de servi�os de sessions.
"Se voc� modelar as classes de maneira diferente (...) essa classe estar� longe de parecer com um EJB" Perfeito! Essa � a id�ia do Business Delegate. Quanto menos esta camada se parecer com EJBs, menor ser� o impacto no caso de mudan�as. "mas voc� estar� fugindo do padr�o EJB " De jeito nenhum! Veja bem, toda a camada de servi�os e o modelo de entidades continua sendo implementado normalmente dentro do servidor de aplica��es, na forma de EJBs. A �nica coisa que muda � a porta de entrada para este mundo, que ser� camuflada para ocultar do cliente todos os detalhes inerentes �s tecnologias espec�ficas que foram utilizadas na recupera��o dos servi�os enterprise como JNDI, narrow, ejbCreates. Curte: 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 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. []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: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
