VOs, TOs e Entidades. Endless story

26 de fevereiro de 2009 4 respostas

Tchello 26 de fevereiro de 2009

Bom dia colegas.

Há algumas semanas me deparei com alguns desafios.
Tive que aprender EJB3 aqui onde trabalho (ainda aprendendo… diga-se de passagem) e mais algumas tecnologias como webServices, etc.

Ainda em fase de treinamento tive contato com um protótipo onde temos a seguinte estrutura:

Base de dados relacional;

Entidades mapeando essa base de dados;

SessionBeans acessando essas entidades;

WebServices disponibilizando essas funções pro sistema (acessado por Conteiners Web em máquinas remotas ou outra aplicação Desktop)

Acontece que na documentação as entidades estão especificadas como… VOs!
Como sou curioso resolvi pesquisar o que seria exatamente esse padrão VO.
Encontrei várias discuções pelo google, incluindo muitas aqui no GUJ de alto nível e o que notei foi uma grande divergência de opiniões, embora tenha sido bastante esclarecedor.

O que me deixou com a pulga atrás da orelha foi a classificação dessas entidades como VOs, pelo que li VOs seriam apenas objeto de armazenamento de valores (como o nome já diz…) e nem costumam ter setters, já entidades seriam uma classificação diferenciada, embora nenhum possuisse comportamento (o que fere OO, mas isso já é outra discução).

Enfim, essa classificação das EntityBeans como VOs está correta? Por que pra mim me parece mais um TO (transfer object) já que eles além de armazenarem valores servem também para o transporte disto através das camadas seja do EJB pro webService ou do webservice pra nuvem.

Um tópico que me auxiliou:
http://www.guj.com.br/posts/list/53305.java

Gostaria de saber se essa minha observação está correta e o que vocês tem a acrescentar, uma vez que embora eu acredite que tenha entendido o conceito ainda me ficou aquela dúvida de “será que entendi corretamente? será que eu aprendi errado?”.
Desculpem-me por criar mais uma thread sobre isso, mas meu espírito não me permite ficar com essa dúvida.

Tenho mais perguntas depois… hehehe

Abraços e muito obrigado pela atenção!

4 Respostas

ffranceschi 26 de fev. de 2009

Agora vou te deixar mais confuso, tem VO e tem VO hehee…
TO, DTO, VO para a Sun é um objeto usado para armazenar valores que nao tem metodos de negocios que são usados para transferir esses valores de uma camada para outra (Tier), esse padrão veio do EJB2.1 pra tras. Livro Core J2EE Pattern
VO em DDD é um objeto que nao tem identidade única. Exemplo uma Moeda.
Entity em DDD é um objeto que tem uma identificação única. Exemplo Pessoa.
No EJB3, vc pode usar o proprio EntityBean para transferir de uma camada para outra

Abraços,

sergiotaborda 26 de fev. de 2009

Não. Ou são entidades ou são VO, não podem seus os dois.
Em EJB 3.0 entities podem ser usada como VO diretamente já que graças à JPA vc pode usar objetos das classes de entidade directamente como VO.
Contudo, conceitualmente eles não são VO. (São no máximo TO)

Muita gente tem a mania de nomear as classes de entidades com a terminação VO ( “ClienteVO” , “PedidoVO”). Isto é uma imbecilidade.
Simples use o nome da entidade puro (“Cliente” , “Pedido”). muito mais simples de ler e entender.

Se vc tem um webservice que expoe objetos esse objetos são TO sim. Do ponto de vista de quem consome o serviço esses objetos são apenas agrupamentos estrutruados de dados que trafegam pela rede. Essa é a definição de TO.
Do ponto de vista interno, os entity beans podem ser usados como esses TO, mas é comum criar uma estrutrua paralela para poder retornar no webservice, porque queremos desacoplar a evolução da aplicação da evolução do contrato do webservice. Ai é natural vc encontrar um ClienteTO ( ou ClienteVO) que é o que o webservice retorna. Mais uma vez não ha necessidade da terminação vO, mas como normalmente temos que trabalhar como Cliente (entidade) e Cliente (vo) no mesmo método é prático terem nomes diferentes.

Veja que esta segunda estrutura não é de dominio, não são entidades, mas apenas objetos de transporte que o webservice usará.

Finalmente, se usa EJB 3.0 o webservice deveria ser Stateless Bean e não haveria necessidade de ir do “EJB para o Webservice” . Basta expor o Bean como um webservice. Isso pouparia uma conversão.

Tchello 26 de fev. de 2009

Poxa, sendo assim vejo que peguei bem o conceito.
Achei realmente muito estranho nomearem as entidades com sufixo VO (PessoaVO, por exemplo), embora sejam entidades do WebService pra frente eles tem o comportamento semelhante ao de TOs.

Muita gente tem a mania de nomear as classes de entidades com a terminação VO ( “ClienteVO” , “PedidoVO”). Isto é uma imbecilidade.
Simples use o nome da entidade puro (“Cliente” , “Pedido”). muito mais simples de ler e entender.

Foi mais ou menos o que se passou na minha cabeça, sem usar o sufixo (erradamente).

Finalmente, se usa EJB 3.0 o webservice deveria ser Stateless Bean e não haveria necessidade de ir do “EJB para o Webservice” . Basta expor o Bean como um webservice. Isso pouparia uma conversão.

Sim, o WebService é Stateless.
No meu projeto teste criei um modulo EJB onde tenho as Stateless SessionBeans, Entity Beans e o meu Stateless WebService, “deployei” tudo junto.
Mas o que você quis dizer exatamente com expor o Bean como um WebService? Estou sentindo que deixei escapar alguma coisa.

Grato pela resposta, foi extremamente esclarecedora.

Tchello 26 de fev. de 2009

Tchello:

Finalmente, se usa EJB 3.0 o webservice deveria ser Stateless Bean e não haveria necessidade de ir do “EJB para o Webservice” . Basta expor o Bean como um webservice. Isso pouparia uma conversão.

Sim, o WebService é Stateless.
No meu projeto teste criei um modulo EJB onde tenho as Stateless SessionBeans, Entity Beans e o meu Stateless WebService, “deployei” tudo junto.
Mas o que você quis dizer exatamente com expor o Bean como um WebService? Estou sentindo que deixei escapar alguma coisa.

Opa, acho que já peguei o que você quis dizer!
Fiz um exemplo aqui onde o WebService É o SessionBean (ou vice e versa), diminuindo um nível provavelmente desnecessário.

Só pra complementar, eu posso implementar minha lógica de persistência com SessionBeans?
Levando em consideração que objetos puros assim já são Anti-OO Isso não entraria naquele conceito anti-pattern de objetos fantoches? FONTE: http://fragmental.com.br/wiki/index.php/Fantoches

Desculpem-me pelo monte de perguntas, preciso esclarecer esse conceitos pra que eu aprenda um dia o conceito verdadeiro de OO, EJB, WebServices, etc… ^^
Abraços!

Edit: erro de concordância.

Criado 26 de fevereiro de 2009

Ultima resposta 26 de fev. de 2009

Respostas 4

Participantes 3

4 Respostas

Topicos relacionados