diferenças minimas ! VO, TO, DTO, POJO

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.

A seguir, o q eu acho.

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.

POJO é o que você usa para fazer a Matrix

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?

Não entendi. Não seria o contrário? VO não é um objeto que representa um valor, como uma data ou dinheiro???

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.

Fabrício Cozer Martins:

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.

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.

Como assim?

renato3110:

Fabrício Cozer Martins:

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.

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.

Como assim?

What?

What?
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.

renato3110:

Não entendi. Não seria o contrário? VO não é um objeto que representa um valor, como uma data ou dinheiro???

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)

Estranho Phillip. Você quer dizer a identidade por referência né? Sim, porque duas notas de dez reais semanticamente são iguais eu penso, certo?

ZehOliveira:

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

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

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

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.

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...

Olá,

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://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Senhores, acredito que o conceito de VO, TO e DTO tenha ficado claro e a literatura (GOF e JEE Patterns) não deixa dúvida. Mas o conceito do POJO não está claro ainda; aí penso se alguém seria capaz de explicar estes conceitos pensando na arquitetura completa de um projeto? Tentarei começar:

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.

Bem, resolvi ressuscitar esse tópico pq estava pesquisando sobre o assunto e esbarrei com ele.

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 ID que a torna única no sistema. Única em termos de dados, não confundir com o Pattern Singleton. E isso difere do conceito de VO: fowler

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

Essa é a sutileza?

Abraços.