O que usar no lugar de VOs?

Aqui sempre vejo muita gente "metendo o pau" em VOs (também chamados de TOs e DTOs). Não use isso, isso é uma gambiarra e blablabla.

Pois bem, vejo muita gente metendo o pau, mas pouca gente propondo uma solução. Que tipo de arquitetura VO-less vocês usam? Onde os dados são armazenados em memória? As classes de negócio tem estados ou não?

Suponha que você tenha um sistema que contém uma classe CellRendererGenerico<? extends VO> e uma classe CellRendererCliente extends CellRendererGenerico<ClienteVO>. Que tipo de refatoramento você faria nas classes CellRendererGenerico e CellRendererCliente?

This message was edited 1 time. Last update was at 06/02/2008 14:49:23

Princípio da OO: manter dados e lógica no mesmo objeto.

Vc nao precisa necessariamente programar Orientado a Objetos. Frameworks como o BC4J da Oracle, e o JCompany, usam objetos que só representam estado. E ja ouvi argumentos como o de 'performance' ( ... a, ta bom, vc vai instanciar 10000 objetos prum relatorio, tendo estado em todos eles?... ), a favor de usar VO.

Mas sei lá... vai de analisar e ver qual sua necessidade.

Já o pessoal do Design-Domain Drive
Fala do uso de VO... ...

tb gostaria de saber ... pq o pessoal não gosta?

This message was edited 1 time. Last update was at 06/02/2008 15:04:53

sandeco wrote:Já o pessoal do Design-Domain Drive
Fala do uso de VO... ...

tb gostaria de saber ... pq o pessoal não gosta?

O VO que o pessoal de Domain-Driven Design fala não é o mesmo que o Data Transfer Object (DTO, nome atual do antigo VO catalogado pela Sun). O Value Object de DDD é um objeto que armazena valores, que não possui identidade ou ciclo de vida e deve ser imutável. Já o Value Object da Sun é um objeto que possui apenas dados, como se fossem os structs de C ou os records de Pascal. Seu uso deve ser empregado em ambientes onde serializar um objeto pode ser custoso (um ambiente distribuído, por exemplo).

Não confunda ValueObject [Fowler] com DTO[CoreJ2EEPatterns]. ValueObject é um conceito de dominio.

Atualmente trabalhamos com POJOS. Não temos problemas em criar um CellRenderer<PedidoVenda>. Este pedido venda pode ser um @Entity, é persistente, pode ter métodos de negócio e não é um DTO.

Java Ninja Membro desde: 03/03/2005 09:53:07 Mensagens: 275 Offline

ok, vamos manter dados e lógica no mesmo objeto.
Nossa classe "QualquercoisaVO" agora vai se chamar "Qualquercoisa" e então terá uma série de métodos.

Mas com certeza teremos que trafegar o objeto "qualquercoisa" pelas camadas da nossa aplicação.

Como fica isso quanto a performance/serialização desse objeto ?

andersonlfl wrote:ok, vamos manter dados e lógica no mesmo objeto.
Nossa classe "QualquercoisaVO" agora vai se chamar "Qualquercoisa" e então terá uma série de métodos.

Mas com certeza teremos que trafegar o objeto "qualquercoisa" pelas camadas da nossa aplicação.

Como fica isso quanto a performance/serialização desse objeto ?

Não só uma serie de métodos mas também uma série de associações de negócio. O "Qualquer coisa" trafega sim pelas camadas da nossa aplicação sem problemas pois é um POJO (não confuda POJO com DTO). Esse objeto é serializado e trafegado da mesma forma que ocorre com o DTO, pois a serialização é com relação ao estado.

As camadas são lógicas e não fisicas. Não tem problema manusear uma Entidade na camada de view, como exemplo. De qualquer forma, não é qualquer aplicação que precisa serializar objetos. Uma aplicação web comum não usa isso. Não distribua seus objetos.

This message was edited 3 times. Last update was at 07/02/2008 11:11:52

andersonlfl wrote:Mas com certeza teremos que trafegar o objeto "qualquercoisa" pelas camadas da nossa aplicação.

Esse foi o principal engano que todo mundo causou com os DTOs. Eles foram feitos para diminuir o overhead do tráfego de rede, no tráfegos de objetos pelas camadas de rede(tiers/física) da sua aplicação, e não nas camadas da aplicação(layers/lógica).

andersonlfl wrote:Como fica isso quanto a performance/serialização desse objeto ?

Java Ninja Membro desde: 03/03/2005 09:53:07 Mensagens: 275 Offline

rodrigoy wrote:As camadas são lógicas e não fisicas. Não tem problema manusear uma Entidade na camada de view, como exemplo.

Tem razão, afinal o que trafega pelas camadas da aplicação é na verdade um endereço de memória e não um objeto em si.

E quanto ao Hibernate?
Tenho um "Qualquercoisa.hbm" representando um "xxx.Model.Qualquercoisa"
Esse cara guarda os estados que serão populados na base. Aqui meu objeto será serializado certo ? Se meu model "Qualquercoisa" agora tem uma série de métodos e associações de negócios, a performance/serialização disso não será prejudicada ?

andersonlfl wrote:

rodrigoy wrote:As camadas são lógicas e não fisicas. Não tem problema manusear uma Entidade na camada de view, como exemplo.

Tem razão, afinal o que trafega pelas camadas da aplicação é na verdade um endereço de memória e não um objeto em si.

E quanto ao Hibernate?
Tenho um "Qualquercoisa.hbm" representando um "xxx.Model.Qualquercoisa"
Esse cara guarda os estados que serão populados na base. Aqui meu objeto será serializado certo ? Se meu model "Qualquercoisa" agora tem uma série de métodos e associações de negócios, a performance/serialização
disso não será prejudicada ?

Pelo que eu sei, não é assim que a banda toca. Já pensou se você tivesse 1000 objetos da sua classe QualquerCoisa instanciados, sendo que QualquerCoisa declara 4 métodos e esses métodos também fossem "instanciados", ou seja, se houvesse 4000 métodos em memória?
Não é assim que acontece, os objetos possuem apenas seu respectivo estado. O código dos métodos está em algum lugar da memória mas é compartilhado por todas as intâncias. Logo, serialização não tem relação alguma com os métodos, métodos não são serializados, apenas dados (estado).

Alguém por favor me corrija se falei besteira

This message was edited 2 times. Last update was at 07/02/2008 12:52:03

cassio wrote:
...

Certo. O que ocorre é que nos primeiros 4 ou 8 bytes de memória alocado a um objeto existe uma referência à classe deste (que pode ser obtida pelo método getClass()). Após estes primeiros bytes, seguem os demais campos pertencentes ao objeto. Primeiro os da superclasses e depois os das subclasses, e na ordem em que são declarados. Os métodos e construtores são referenciados no objeto Class, que mantém uma estrutura de dados com ponteiros para os métodos e construtores. Na inicialização de Class estes ponteiros são inicializados com cópias dos ponteiros dos métodos da superclasse, alguns destes são sobrescritos por outros métodos (e aí ocorre a sobrescrita) e são adicionados mais alguns ponteiros para os métodos novos.

Mas, voltando ao foco do tópico:

O VO (ou TO, ou DTO) contém getters e setters burros para todos os seus campos, o que não provê um encapsulamento verdadeiro (dá quase na mesma que ter todos os atributos públicos). Como objeto de negócio, apenas métodos de mais alto nível acessam os campos, provendo um encapsulamento verdadeiro, o que dispensa a necessidade da maior parte dos getters e setters.

Mas, e quando você utiliza algum tipo de framework, tal como Hibernate ou algo baseado em Reflection para construir ou alterar instâncias dinamicamente? Como você evita de ter que colocar getters e setters para todos os campos deixando o encapsulamento fraco e ao mesmo tempo permitindo que o tal framework faça o seu serviço direito?

victorwss wrote:

cassio wrote:
...

Certo. O que ocorre é que nos primeiros 4 ou 8 bytes de memória alocado a um objeto existe uma referência à classe deste (que pode ser obtida pelo método getClass()). Após estes primeiros bytes, seguem os demais campos pertencentes ao objeto. Primeiro os da superclasses e depois os das subclasses, e na ordem em que são declarados. Os métodos e construtores são referenciados no objeto Class, que mantém uma estrutura de dados com ponteiros para os métodos e construtores. Na inicialização de Class estes ponteiros são inicializados com cópias dos ponteiros dos métodos da superclasse, alguns destes são sobrescritos por outros métodos (e aí ocorre a sobrescrita) e são adicionados mais alguns ponteiros para os métodos novos.

Mas, voltando ao foco do tópico:

O VO (ou TO, ou DTO) contém getters e setters burros para todos os seus campos, o que não provê um encapsulamento verdadeiro (dá quase na mesma que ter todos os atributos públicos). Como objeto de negócio, apenas métodos de mais alto nível acessam os campos, provendo um encapsulamento verdadeiro, o que dispensa a necessidade da maior parte dos getters e setters.

Mas, e quando você utiliza algum tipo de framework, tal como Hibernate ou algo baseado em Reflection para construir ou alterar instâncias dinamicamente? Como você evita de ter que colocar getters e setters para todos os campos deixando o encapsulamento fraco e ao mesmo tempo permitindo que o tal framework faça o seu serviço direito?

No Hibernate você tem opção de colocar as annotations direto sobre os atributos ou nos getters (não sei no caso de XML, aprendi Hibernate já usando annotations e não gosto de XML...). No caso de colocar nos atributos, mesmo que esses atributos sejam privados e não existam os respectivos getters e/ou setters, o Hibernate acessa os campos através de reflection e seta/lê os valores sem problemas.

This message was edited 1 time. Last update was at 07/02/2008 14:50:07

"Pelo que eu sei, não é assim que a banda toca. Já pensou se você tivesse 1000 objetos da sua classe QualquerCoisa instanciados, sendo que QualquerCoisa declara 4 métodos e esses métodos também fossem "instanciados", ou seja, se houvesse 4000 métodos em memória?
Não é assim que acontece, os objetos possuem apenas seu respectivo estado. O código dos métodos está em algum lugar da memória mas é compartilhado por todas as intâncias. Logo, serialização não tem relação alguma com os métodos, métodos não são serializados, apenas dados (estado)."

Alguém mais me confirma isso?

Rafael Nunes wrote:

andersonlfl wrote:Mas com certeza teremos que trafegar o objeto "qualquercoisa" pelas camadas da nossa aplicação.

Esse foi o principal engano que todo mundo causou com os DTOs. Eles foram feitos para diminuir o overhead do tráfego de rede, no tráfegos de objetos pelas camadas de rede(tiers/física) da sua aplicação, e não nas camadas da aplicação(layers/lógica).

Perfeito!!! DTO é para trafegar beans entre TIERS, nao entre LAYERS! Entre layers é perfeitamente aceitavel que layers diferentes acessem suas entidades de dominio!

fabiocsi wrote:"Pelo que eu sei, não é assim que a banda toca. Já pensou se você tivesse 1000 objetos da sua classe QualquerCoisa instanciados, sendo que QualquerCoisa declara 4 métodos e esses métodos também fossem "instanciados", ou seja, se houvesse 4000 métodos em memória?
Não é assim que acontece, os objetos possuem apenas seu respectivo estado. O código dos métodos está em algum lugar da memória mas é compartilhado por todas as intâncias. Logo, serialização não tem relação alguma com os métodos, métodos não são serializados, apenas dados (estado)."

Alguém mais me confirma isso?

Sim, é isso.

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