http://www.guj.com.br/posts/list/5.java JForum - http://www.jforum.net
Quais as diferenças entre VO, TO, DTO e POJO

O que eu li até agora
VO e TO são absolutamente iquais, sem qualquer diferença... nem mesmo o contexto da situação muda.

DTO serve para transportar varios TO ou VO, ou seja... vária tabelas ? e pode tb funcionar identico ao VO e o TO.

POJO parecido com VO e TO, porem este pode conter algumas logicas de negocio.
Por exemplo... POJO no hibernate é identico ao VO e TO, serve para persistir dados do banco de dados.
Porem POJO pode ser tb um javaBean ? contendo getters and setters e mais algumas logicas como por exemplo sacar ou depositar dinheiro.

Obrigado.]]> http://www.guj.com.br/posts/preList/31773/170208.java http://www.guj.com.br/posts/preList/31773/170208.java GMT
O resto é enxeção de linguiça e só faz complicar. Pense e programe para objetos, afinal, Java é uma linguagem orientada a objetos e não orientada a value objects, transfer objects ou data transfer objects.

Os transfers objects você só vai precisar em um contexto bem definido (ambiente distribuído), é totalmente anti-pattern usar fora disso.]]> http://www.guj.com.br/posts/preList/31773/170212.java http://www.guj.com.br/posts/preList/31773/170212.java GMT
POJO, VO, DTO e TO são idênticos porém, POJO é um termo usado mais quando estamos falando de padrões GOF, e VO e TO em padrões J2EE.

Ambos são usados para transferir Dados entre as camadas. ]]> http://www.guj.com.br/posts/preList/31773/170213.java http://www.guj.com.br/posts/preList/31773/170213.java GMT ]]> http://www.guj.com.br/posts/preList/31773/170242.java http://www.guj.com.br/posts/preList/31773/170242.java GMT
Quanto ao DTO e TO entendo como o padrão do Core J2EE Patterns, onde estes são utilizados para simplesmente transportar dados de uma camada a outra.

Quanto ao VO, pelo que entendi lendo o livro Model Driven Design (Eric Evans), é uma forma de citar um objeto com getters e setters, no entanto com objetivos diferentes de uma entidade. Por exemplo, uma Entidade pessoa pode ter um VO que seja uma classe do tipo Endereco. Dependendo do contexto, pode acontecer do Endereco ser uma entidade mesmo estando relacionado com o aluno. Meu, o negócio é cavernoso! ]]> http://www.guj.com.br/posts/preList/31773/170282.java http://www.guj.com.br/posts/preList/31773/170282.java GMT Será que vale a pena realmente separar a lógica de negócio da classe de atributos ? É purismo OO , ou uma quebra de encapsulação ?

]]> http://www.guj.com.br/posts/preList/31773/170297.java http://www.guj.com.br/posts/preList/31773/170297.java GMT
O problema não é purismo, mas as desvantagens que programação procedural traz pro seu modelo - resusabilidade de código baixa é um exemplo.]]> http://www.guj.com.br/posts/preList/31773/170319.java http://www.guj.com.br/posts/preList/31773/170319.java GMT [url=http://www.martinfowler.com/eaaCatalog/valueObject.html]VO[/url] = objeto cuja identidade é baseada nos valores dos seus atributos.
[url=http://http://java.sun.com/blueprints/patterns/TransferObject.html]TO[/url]==[url=http://www.martinfowler.com/eaaCatalog/dataTransferObject.html]DTO[/url] (ou antigo VO) padrão que compõe vários objetos em um de menor granularidade a fim de reduzir o custo em chamadas remotas.
[url=http://www.martinfowler.com/bliki/POJO.html]POJO[/url] =
[quote=ZehOliveira]POJO, basicamente, é um objeto normal que não estende ou implementa nenhuma classe ou interface de infra-estrutura (nenhuma classe de framework, por exemplo). [/quote]
É isso aí.

[quote=Fabrício Cozer Martins]... vale a pena realmente separar a lógica de negócio da classe de atributos ?...[/quote]
Em geral, você não deve separar a lógica dos dados. Manter isso junto, é um passo para garantir um bom encapsulamento. [url=http://www.fragmental.com.br/wiki/index.php?title=Fantoches]Exemplo?[/url]]]> http://www.guj.com.br/posts/preList/31773/170330.java http://www.guj.com.br/posts/preList/31773/170330.java GMT [url=http://www.martinfowler.com/eaaCatalog/valueObject.html]VO[/url] = objeto cuja identidade é baseada nos valores dos seus atributos.
[/quote]

[quote=Fowler]A small simple object, like money or a date range, whose equality [b]isn't[/b] based on identity.[/quote]

Não entendi. Não seria o contrário? VO não é um objeto que representa um valor, como uma data ou dinheiro???]]> http://www.guj.com.br/posts/preList/31773/170355.java http://www.guj.com.br/posts/preList/31773/170355.java GMT
O problema não é purismo, mas as desvantagens que programação procedural traz pro seu modelo - resusabilidade de código baixa é um exemplo.[/quote]
Então temos um duelo entre :
Separação de Atributos da lógica do negócio x Transportar a lógica do negócio para as outras camadas.

]]> http://www.guj.com.br/posts/preList/31773/170386.java http://www.guj.com.br/posts/preList/31773/170386.java GMT
O problema não é purismo, mas as desvantagens que programação procedural traz pro seu modelo - resusabilidade de código baixa é um exemplo.[/quote]
Então temos um duelo entre :
Separação de Atributos da lógica do negócio x Transportar a lógica do negócio para as outras camadas.

[/quote]

Como assim?]]> http://www.guj.com.br/posts/preList/31773/170408.java http://www.guj.com.br/posts/preList/31773/170408.java GMT
O problema não é purismo, mas as desvantagens que programação procedural traz pro seu modelo - resusabilidade de código baixa é um exemplo.[/quote]
Então temos um duelo entre :
Separação de Atributos da lógica do negócio x Transportar a lógica do negócio para as outras camadas.

[/quote]

Como assim?[/quote]
Com um TO, vc transportaria somente os dados, sem bussiness rules para as outras camadas, e sem TO, vc transportaria os dados, junto com as bussiness rules.




]]> http://www.guj.com.br/posts/preList/31773/170410.java http://www.guj.com.br/posts/preList/31773/170410.java GMT What?]]> http://www.guj.com.br/posts/preList/31773/170411.java http://www.guj.com.br/posts/preList/31773/170411.java GMT What?[/quote]
o que eu quis dizer é que na tela, onde os dados seriam apenas para preencher os componentes visuais, os mesmos estariam encapsulados dentro de um objeto apenas, que faz uma operação de negócio complexa, isso claro se vocÊ colocar tudo em um objeto só (sem TO), isso pode quebrar a encapsulação entre camadas.]]> http://www.guj.com.br/posts/preList/31773/170415.java http://www.guj.com.br/posts/preList/31773/170415.java GMT [url=http://http://java.sun.com/blueprints/patterns/TransferObject.html]TO[/url]==[url=http://www.martinfowler.com/eaaCatalog/dataTransferObject.html]DTO[/url] (ou antigo VO) padrão que compõe vários objetos em um de menor granularidade a fim de reduzir o custo em chamadas remotas.
[/quote]

Só um comentário: TO é uma especialização de DTO para EJBs, principalmente Entity Beans. Basicamente um TO não precisa atravessar Camadas, ao contrário de um DTO. Fora deste contexto não há motivo para usar TO, use o termo genérico.]]> http://www.guj.com.br/posts/preList/31773/170422.java http://www.guj.com.br/posts/preList/31773/170422.java GMT Não entendi. Não seria o contrário? VO não é um objeto que representa um valor, como uma data ou dinheiro???[/quote]

Se você me emprestar uma nota de R$10,00 e eu te evolver uma nota de R$10,00 você vai se importar com:

1) A nota ser a mesma (identidade)
ou
2) Eu te retornar a quantidade emprestada (valor)]]> http://www.guj.com.br/posts/preList/31773/170437.java http://www.guj.com.br/posts/preList/31773/170437.java GMT http://www.guj.com.br/posts/preList/31773/170461.java http://www.guj.com.br/posts/preList/31773/170461.java GMT ent1.setCodigo(1);

Entidade ent2 = new Entidade();
ent2.setCodigo(1);

Entidade ent3 = new Entidade();
ent3.setCodigo(1);[/code]
Se codigo for a chave da entidade, eles são iguais em termos de Value Object. Isto é, quando se fala de VOs, instâncias diferentes com mesmo valor são consideradas iguais.]]> http://www.guj.com.br/posts/preList/31773/170465.java http://www.guj.com.br/posts/preList/31773/170465.java GMT ent1.setCodigo(1);

Entidade ent2 = new Entidade();
ent2.setCodigo(1);

Entidade ent3 = new Entidade();
ent3.setCodigo(1);[/code]
Se codigo for a chave da entidade, eles são iguais em termos de Value Object. Isto é, quando se fala de VOs, instâncias diferentes com mesmo valor são consideradas iguais.[/quote]

EDITADO!

Não exatamente pelo o que entendo (não apenas com os VOs). Eu posso considerar duas pessoas iguais através de um código como RG ou CPF, mas você chamaria essas pessoas de VOs?

Um VO é um objeto cuja essência é representar um valor pelo o que entendo, não é apenas um objeto com identidade semântica...]]> http://www.guj.com.br/posts/preList/31773/170510.java http://www.guj.com.br/posts/preList/31773/170510.java GMT
A diferença é conceitual:

VO - Value Object: mapear dados da aplicação. Esses dados podem ser, por exemplo, as tuplas do seu MER ou dados de XML.

DTO = TO - Data Transfer Object: transferir conjunto de dados entre camadas ou susbsistemas da aplicação. É utilizado quando você precisa transportar dados com relacionamento complexo, o tranporte neste conceito de dá entre:

- entre camadas do seu sistema;
- entre subsistemas;
- entre a sua aplicação e uma entidade externa.

O DTO é uma classe que receberá VO's + conjunto de dados e cuidará da associação entre esses dados - para que estejam íntegros na passaem entre as camadas ou subsistemas.

A primeira vista, pode não parecer, mas esta separação de responsabilidades é importantíssima para um grande projeto.

POJO - Plain old java object: é uma classe pura java, que não está acoplada(conceito acoplamento OO) a nenhum framework.

Att,
Emerson Aguiar Noronha
]]> http://www.guj.com.br/posts/preList/31773/170570.java http://www.guj.com.br/posts/preList/31773/170570.java GMT http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs]]> http://www.guj.com.br/posts/preList/31773/257923.java http://www.guj.com.br/posts/preList/31773/257923.java GMT Pensando em JSF:
1 - JSP submete a página, a requisição é interceptada por um CONTROLADOR(Servlet JSF) e alimenta um BEAN
2 - Caso existam, os dados são validados por VALIDATORS JSF
3 - Após a validação são chamados objetos de negócio (POJOs) que fazem o processamento dos dados(sacar, transferir, depositar) e chamam um FACADE para chamar as operações de banco;
4 - É criado um DAO que mascara as opções de banco (incluir, alterar, excluir e consultar)
5 - O dado é persistido.

Lembrando: É "RECOMENDÁVEL" que o POJO não extenda ou herde de nenhuma classe, mas se o fizer que exteda ou implemente classes e interfaces de negócio, não de infra-estrutura (como frameworks).

Será que falei alguma coisa errada?

Um abraço,
Novais.
]]> http://www.guj.com.br/posts/preList/31773/284826.java http://www.guj.com.br/posts/preList/31773/284826.java GMT
Pela parábola do empréstimo de 10,00 do Philipp, tirei alguma conclusão, mas preciso de certeza. Fui discutir essa pendenga por aqui e, para variar, rolou uma baita divergência de opnião. É muito difícil estudar sobre esses assuntos, principalmente na Internet, pois parece não haver um consenso sobre o assunto.

Pelo que entendi:

Entity != VO (ou TO). E NUNCA será igual.

Basicamente porque Entity, normalmente, possui um [b]ID[/b] que a torna única no sistema. Única em termos de dados, não confundir com o Pattern [i]Singleton[/i]. E isso difere do conceito de VO: [url=http://www.martinfowler.com/eaaCatalog/valueObject.html]fowler[/url]

Foi a mesma coisa que entendi no artigo da MJ do Sérgio Lopes.

Essa é a sutileza?

Abraços.
]]> http://www.guj.com.br/posts/preList/31773/562201.java http://www.guj.com.br/posts/preList/31773/562201.java GMT