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.
POJO, basicamente, é um objeto normal que não estende ou implementa nenhuma classe ou interface de infra-estrutura (nenhuma classe de framework, por exemplo).
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.
Quanto a uma definição de POJO, eu fico com a que o Zeh Oliveira citou.
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!
A questão que venho me pergutando hoje é:
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 ?
É anti-OO. Programando com lógica separada de atributos você não tem muito mais que um aglomerado de funções e algumas structs (bom e velho C). Isso é programação procedural…
O problema não é purismo, mas as desvantagens que programação procedural traz pro seu modelo - resusabilidade de código baixa é um exemplo.
VO = objeto cuja identidade é baseada nos valores dos seus atributos. TO==DTO (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. POJO =
É isso aí.
Em geral, você não deve separar a lógica dos dados. Manter isso junto, é um passo para garantir um bom encapsulamento. Exemplo?
[quote=ZehOliveira]É anti-OO. Programando com lógica separada de atributos você não tem muito mais que um aglomerado de funções e algumas structs (bom e velho C). Isso é programação procedural…
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=Fabrício Cozer Martins][quote=ZehOliveira]É anti-OO. Programando com lógica separada de atributos você não tem muito mais que um aglomerado de funções e algumas structs (bom e velho C). Isso é programação procedural…
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=renato3110][quote=Fabrício Cozer Martins][quote=ZehOliveira]É anti-OO. Programando com lógica separada de atributos você não tem muito mais que um aglomerado de funções e algumas structs (bom e velho C). Isso é programação procedural…
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.
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.
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.
[code]Entidade ent1 = new Entidade();
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=ZehOliveira][code]Entidade ent1 = new Entidade();
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…
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.
