Bom Emerson, Existe o Version Number Pattern que funciona exatamente como voc� descreveu: A gente simplesmente adiciona um integer ao entity bean como um atributo membro.O prop�stio deste integer vai ser justamente identificar o estado de um entity bean num certo ponto.Isso � feito � partir do incremento do VERSION NUMBER do bean em qualquer momento que o entity bean � atualizado. Como � feito o controle? 1) � s� carregar o VERSION NUMBER junto com o entity bean em qualquer transa��o de leitura. 2) Mandar o VERSION NUMBER de volta pro entity bean junto com os dados que foram atualizados. 3) Quando for feito um update, fazer um incremento no VERSION NUMBER. 4) Rejeitar o update se a vers�o n�o bater. (lan�ar uma exce��o). 5) Avisar ao usu�rio (2) que est� tentando fazer o update do dado antigo, que algu�m j� fez aquela atualiza��o e que ele deveria tentar novamente.
Se vc estiver utilizando o PATTERN DTO, vc faz o get da vers�o quando fizer o getXXXDTO e vc checa a vers�o no m�todo setXXXDTO. Outra maneira, a usada atualmente no meu projeto, �, quando vc for fazer deploy, setar atributos transacionais para um ou mais valores no deployment descriptor da tua aplica��o (que s�o verificados em tempo de deploy). Baseado nestes atributos transacionais, o container vai gerenciar as tuas transa��es. Se n�o me falhe a mem�ria, os atributos s�o os seguintes: 1 NotSupported Caso invoque um m�todo num EJB com este atributo, a transa��o ser� suspensa at� que o m�todo seja completo. 2 Supports Significa que o m�todo do bean ser� inclu�do no escopo da transa��o que o invocou 3 Required Significa que o m�todo de um EJB DEVE ser invocado de dentro do escopo de uma transa��o. 4 RequiresNew Significa que uma nova transa��o SEMPRE ser� iniciada, independentemente se o cliente que fez a chamada faz parte de uma transa��o. 5 Mandatory Significa que o m�todo deve SEMPRE fazer parte do escopo da transa��o do cliente. Se o cliente que est� chamando o m�todo ou o EJB n�o forem parte da transa��o, lan�a, se n�o me engano, uma TransactionRequiredException. 6 Never Este significa que o m�todo do bean n�o deve ser invocado de dentro do escopo de uma transa��o. Bem, sei que a descri��o foi meio breve mas se precisar de mais detalhes, � s� falar! []�s! -----Mensagem original----- De: Emerson Cargnin - SICREDI Servi�os [mailto:emersonc@;sicredi.com.br] Enviada em: 5 de novembro de 2002 10:41 Para: [EMAIL PROTECTED] Assunto: Re: [enterprise-list] classes DAO/Value Object Como vcs est�o fazendo controle de vers�o de VO's (ou DTO's)? digo, qdo alguem pega um entity para alterar, vcs est�o usando o esquema de timestamp para pegar a vers�o daquele objeto e fazer um lock otimista, gerando uma exce��o de neg�cio para o �ltimo que tentar alterar o objeto (agora inconsistente) ? qdo a discuss�o sobre VO/DTO, acho que deve haver os dois, DTO's para mapear os dados necess�rios a uma tela (nossa conex�o de rede � cara e com delay, via sat�lite, e devemos ter todos os dados transferidos de uma vez) e VO's para encapsular os dados para altera��o/inser��o. Michael Nascimento Santos wrote: > Paulo, > > Realmente alguns autores acham que os TOs devem ser read-only. No entanto, o > catalogo de patterns novamente mostra que isso eh recomendavel mas que pode > ser interessante poder alterar os TOs. > > Acho que nao fui muito claro na minha colocacao. O uso de TOs complexos > geralmente serve para que o cliente localize a entidade que quer manipular. > Um exemplo simples de um sistema web: > > Numa console administrativa de um site de vendas, o usuario pode querer > visualizar diversos pedidos com cruzamentos de informacoes para localizar > aquele que precisa editar. Depois disso, normalmente ele vai selecionar um > pedido que serah retornado com mais informacoes complexas, mas geralmente > ele soh vai alterar um aspecto do pedido (por exemplo, validar o estoque, ou > mudar o status para atendido, ou ainda cancelar etc.), que geralmente vai > estar ou na entidade principal ou em um tipo de entidade relacionada (item > do pedido, por exemplo). > > Se voce pensar bem, dificilmente o usuario ou um sistema cliente vai alterar > muitos dados _relacionados_ de uma vez. Ele pode ateh alterar varios dados > de varias entidades, mas geralmente sao do mesmo tipo. Dificilmente isso > ocorre, mesmo em EAI. > > O uso de TOs complexos para atualizacoes eh raramente necessario. > > Espero que tenha ficado claro agora. Caso discorde, mande seus comentarios. > A discussao estah comecando a ficar bem interessante. > > []s > Michael Nascimento Santos > Sun Certified Programmer for the Java 2 Platform > Sun Certified Programmer for the Java 2 Platform 1.4 > Moderador SouJava - www.soujava.org > > ----- Original Message ----- > From: "Paulo Andre Antonialli" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 05, 2002 10:41 AM > Subject: RES: [enterprise-list] classes DAO/Value Object > > > Ok Michael. Realmente acho que deveria ter adicionado a palavra > "recomend�vel", s� n�o o fiz porque lembro-me de haver lido n�o sei onde que > o cliente obt�m Transfer Objects com o �NICO prop�sito de usar estes objetos > de forma read-only. > > Bem, quanto � complexidade de se descobrir quais foram os dados alterados > pelo cliente, tenho uma pondera��o a fazer: J� participei de algumas > discuss�es sobre este assunto e, at� onde minha ignor�ncia vai, eu n�o vejo > problema nenhum nesta quest�o, pelo menos utilizando um VO. Me corrijam se > eu estiver errado mas, ao inv�s de bolar toda uma l�gica de "descobrimento > dos dados alterados na camada cliente", por que n�o simplesmente setar logo > TODOS os dados num VO e passar este VO pra camada de neg�cio? � claro que > estar�amos fazendo alguns sets desnecess�rios (aqueles atributos que n�o > foram alterados na camada cliente) mas, como todos estes dados estariam > encapsulados num VO, isto n�o acarretaria em overhead de rede por exemplo e > me pouparia uma l�gica respeit�vel. > > Any comments? > []�s! > > > -----Mensagem original----- > De: Michael Nascimento Santos [mailto:mister__m@;hotmail.com] > Enviada em: 5 de novembro de 2002 10:20 > Para: [EMAIL PROTECTED] > Assunto: Re: [enterprise-list] classes DAO/Value Object > > Paulo, > > Eh muito bom ter mais alguem participando nesta discussao. Seu comentario > foi bastante relevante. > > No entanto, nao necessariamente os TOs gerados pelo Transfer Object > Assembler sao read-only; isto eh recomendavel devido a complexidade de saber > exatamente o que o usuario alterou, mas nao eh obrigatorio. > > Geralmente, quando o usuario faz uma atualizacao, ele estah mexendo em > somente _uma_ entidade. O que acontece geralmente eh que voce primeiro > retorna TOs complexos para que o usuario possa localizar a entidade exata > que quer modificar e depois edita somente aquela entidade especifica, que > pode ser representada por um TO simples. > > Caso nao tenha ficado claro, nao hesite em perguntar. > > []s > Michael Nascimento Santos > Sun Certified Programmer for the Java 2 Platform > Sun Certified Programmer for the Java 2 Platform 1.4 > Moderador SouJava - www.soujava.org > > ----- Original Message ----- > From: "Paulo Andre Antonialli" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 05, 2002 10:06 AM > Subject: RES: [enterprise-list] classes DAO/Value Object > > > Mas acho que cabe ressaltar a import�ncia do contexto da sua aplica��o pois, > at� onde sei, o Transfer Object Assembler � read-only, ou seja, � um pacote > de dados (coletado de v�rias entities, etc) que v�o ser expostos ao cliente. > At� a� tudo bem, o problema � que, se por exemplo, eu quiser alterar estes > dados e atualizar no banco, o Transfer Object Assembler n�o conseguir� > realizar esta tarefa. Acho que neste caso, o mais apropriado seria usar um > VO (value object) onde, caso eu queira atualizar dados numa tabela, eu posso > construir este vo (no cliente) e mandar para minha camada de neg�cio. > > []�s! > > > -----Mensagem original----- > De: Michael Santos [mailto:mister__m@;hotmail.com] > Enviada em: 4 de novembro de 2002 23:24 > Para: [EMAIL PROTECTED] > Assunto: Re: [enterprise-list] classes DAO/Value Object > > Transfer Object Assembler eh um design pattern para a construcao de um > Transfer Object complexo, ou seja, cujos dados vem de diversas fontes > distintas. Mais informacoes em > http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssem > bler.html > > -- > Michael Nascimento Santos > Sun Certified Programmer for the Java 2 Platform > Sun Certified Programmer for the Java 2 Platform 1.4 > Moderador SouJava - www.soujava.org.br > > ----- Original Message ----- > From: "Fernando Rubbo" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, November 04, 2002 4:09 PM > Subject: RES: [enterprise-list] classes DAO/Value Object > > > Michael > Eu esqueci de pedir... o que eh Transfer Object Assembler??? > Valeu > Fernando > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- > 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] > > -- 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] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
