Ok, fa�amos como o Jack estripador, vamos por partes =)
>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. At� aqui tudo bem. Bem, tomei o cuidado de entrar no site da sun q vc passou como refer�ncia e percebi que n�o havia a descri��o do pattern Value Object. Por um acaso, esse Transfer Object � um novo nome para o Value Object? >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. Ok Michael, entendi perfeitamente seu exemplo. O que voc� est� querendo dizer ent�o � que, quando vou fazer uma a��o de consulta, geralmente utilizo um Transfer Object Assembler mas, por exemplo, se eu quero alterar o conjunto de dados de algum dos retornos da consulta, a� sim eu j� traria este conjunto de dados (de determinada entity) encapsulados num Transfer Object, correto? Exemplo: Quero achar todos os caras com o nome de Jo�o. Eu usaria um transfer object assembler que retornaria o seguinte: Nome Sobrenome: Jo�o Silva Jo�o Marques Jo�o Antony J�ao Collor Pois bem, depois de realizada esta consulta, se eu selecionar o Jo�o Silva para alterar, a� sim, meu cliente vai fazer uso somente do Transfer Object porque ele faz a mesma fun��o do VO (representa os dados de uma entity, no caso, a Entity Jo�o Silva), correto? Espero n�o estar sendo inc�modo. []�s! ----- 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] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
