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

Pessoal

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.

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.

JavaGuru Membro desde: 22/02/2005 19:46:49 Mensagens: 205 Offline

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.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

POJO é o que você usa para fazer a Matrix

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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.

JavaBaby Membro desde: 14/04/2006 19:28:16 Mensagens: 79 Offline

ronildobraga wrote:Quais as diferenças entre VO, TO, DTO e POJO

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 =

ZehOliveira wrote:POJO, basicamente, é um objeto normal que não estende ou implementa nenhuma classe ou interface de infra-estrutura (nenhuma classe de framework, por exemplo).

É isso aí.

Fabrício Cozer Martins wrote:... vale a pena realmente separar a lógica de negócio da classe de atributos ?...

Em geral, você não deve separar a lógica dos dados. Manter isso junto, é um passo para garantir um bom encapsulamento. Exemplo?

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

TheMask wrote:
VO = objeto cuja identidade é baseada nos valores dos seus atributos.

Fowler wrote:A small simple object, like money or a date range, whose equality isn't based on identity.

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

ZehOliveira wrote:É 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.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Fabrício Cozer Martins wrote:

ZehOliveira wrote:É 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 wrote:

Fabrício Cozer Martins wrote:

ZehOliveira wrote:É 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?

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.

Fabrício Cozer Martins wrote:Transportar a lógica do negócio para as outras camadas.

What?

ZehOliveira wrote:

Fabrício Cozer Martins wrote:Transportar a lógica do negócio para as outras camadas.

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.

TheMask wrote:
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.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java