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]
