Evitando VOs e BOs

Programação Arquitetura
#41

Eu baixei a apostila FJ-28 da Caelum que demonstra uma aplicação web.

Lá o código está assim:

public class Usuario {
   //atributos

  //getters and setters
}

representa a tabele usuario no banco de dados

e

public class UsuarioLogic {

}

é onde tem os métodos de salvar, atualizar, buscar, mostrarPorPerfil e etc, e é nessa classe que é chamada o DAO, e os métodos recebem um Usuario como parâmetro de entrada.

Bom, me desculpem se eu tiver errado, mas pra mim isso não deixa de ser um VO e um BO, a única diferença é que não tem as siglas no fim do nome. A lógica está separada dos atributos do objeto.

Então, eu tbm estou com o mesmo problema do Ronildo. Eu sei que BO e VO são ruins. Mas, como fazer então?

Até aonde eu tinha entendido, para serguir o q o PC fala, os métodos salvar, buscar deveriam estar dentro da entidade Usuario e não na classe UsuarioLogic. Mas se for isso…então o exemplo da apostila tah, digamos “errado”? O que ateh seria compreensivel, por se tratar de algo didático, mas eu queria saber se eu que to entendendo errado ou se é na apostila que tah errado.

Valeu Pessoal!

#42

[quote=ronildobraga]
Tudo bem, entao entendemos que o VO e o BO deve ser descartado e virar uma coisa só, pois o BO é dependente do VO como diz no artigo, mas sinceramente nao vejo como fazer isso, pois os VOs representam os meus registros no banco de dados, e eu nao vou amarrar logica aos meus registros… ou pelo menos nao acho isso muito correto.[/quote]

Ronildo, o problema é que você não deve pensar em registros do banco de dados e sim em objetos. Quando se modela um sistem OO não se pensa em primeiro lugar nos objetos daquele domínio.

Esse parece ser o motivo real de toda a confusão. É legal você dar uma olha da em outros textos de OO como os livros do Craig larman e Page-Jones.

#43

Creio que não entendi bem essa parte de amarrar registros do banco com lógica de negócio. Você diz ter um objeto Usuário com atributos retornados do banco e os métodos que manipular estes atributos dentro de um objeto só?

[quote=ronildobraga]
So para adiantar, creio que vc deva sugerir usar um POJO para representar os registros no banco de dados.
Portanto teriamos a entidade Usuario e o POJO usuario ? nao vejo muito sentido nisso, pois pra mim um POJO nao é nada mais que um VO.[/quote]
Mais ou menos, o seu POJO é a sua entidade e não uma classe separada. A sua entidade Usuario é um objeto Usuario com os atributos referentes ao Usuario e os metodos de manipulacao deste Usuario. Ou seja, um POJO.

#44

[quote=Rafael Nunes]

[quote=ronildobraga]
So para adiantar, creio que vc deva sugerir usar um POJO para representar os registros no banco de dados.
Portanto teriamos a entidade Usuario e o POJO usuario ? nao vejo muito sentido nisso, pois pra mim um POJO nao é nada mais que um VO.[/quote]
Mais ou menos, o seu POJO é a sua entidade e não uma classe separada. A sua entidade Usuario é um objeto Usuario com os atributos referentes ao Usuario e os metodos de manipulacao deste Usuario. Ou seja, um POJO.[/quote]

O que está em causa é a definição de "metodos de manipulação"
Num DTO esses métodos são getters e setters. Em DDD esses métodos seriam ,além dos getters e setters, getGroup():Group, login() , sei lá… métodos do dominio.
O que está sendo usado pelo colega é só a parte de get/set. Então isso é um TO já que não contem métodos de negocio. Esses estão em outros objetos “de serviço” como aquele “UsuarioLogic” do exemplo.
Este paradigma (TO+Serviço) é incompativel com o paradigma de Entidades e o DDD ? Essa é a questão. A resposta é sim.
E a pergunta é: Então como implementar DDD sem TO nem serviços como UsuárioLogic.

#45

Eu ate pensei primeiro nos objetos, mas o que aconteceu é que meus objetos agora precisam resolver um problema no mundo real. Eu nao sou IDIOTA e ate entendo o que vc queria dizer no artigo, o problema é que vc postou esse artigo no meu blog e achei que este poderia resolver um problema que eu nao tinha enxergado e que provavelmente me traria problemas.
Eu ate posso ler alguns livros para buscar a solução, assim como eu passei o final de semana lendo os artigos, MAS EU SINCERAMENTE esperava que vc podia mostrar algumas perspectivas suas sobre o assunto, assim como o Luca fez fazendo referencia ao uso do EJB.
INFELISMENTE o link que vc indicou como provavel solução indica apenas discussoes e elogios sobre a sua materia na revista, revista o qual ja nao esta mais nas bancas.

O problema que ocorre é referente justamente aos codigos que estao no meu blog, pois lá nos temos o classico VO ou DTO ou POJO como queiram representando os registros no banco de dados e o BO que faz uso indiretamente do VO através de DAO.

#46

[quote=ronildobraga ]Desculpa… nao tive aulas do genero… mas estou entendendo assim mesmo… quando eu puder eu procuro as aulas, Obrigado.
[/quote]

Olá Ronildo. Desculpa! Não era minha intenção desmerecê-lo. Só depois da sua resposta vi que fui infeliz na forma como me expressei. Mas enfim a minha idéia era exatamente ressuscitar o bom e antigo OO que tanto ouvi dizerem que era a teoria bonitinha impossível de aplicar no mundo real. :wink:

#47

[quote=ronildobraga][quote=pcalcado]
O problema que ocorre é referente justamente aos codigos que estao no meu blog, pois lá nos temos o classico VO ou DTO ou POJO como queiram representando os registros no banco de dados e o BO que faz uso indiretamente do VO através de DAO.[/quote]

cara
aí é que está o problema
objetos de negócio não foram feitos para representar tabelas, você não deve ter um “objeto representando os registros no banco de dados”

#48

Ótimo questionamento!

Mas cuidado! Não é porque existe a UsuarioLogic na apostila do FJ-28 que ela é um BO. Como entidade do domínio, um Usuario pode (e deve) continuar tendo comportamento e sendo parte de um modelo rico.

A UsuarioLogic não está lá para ter o comportamento de Usuarios. Está lá para receber e tratar requisições da web, como um componente que expõe as funcionalidades do sistema.

Lembrando denovo que ela não deve apenas manipular um objeto/estrutura Usuario anêmico e burro. E sim delegar as tarefas adequadas aos objetos de domínio pertinentes, como um Usuario com comportamento bem definido.

Acontece que o exemplo da apostila é muito simples. Nem tem regra de negócio alguma, por isso o Usuario está parecendo anêmico.

#49

Eu nao entendi como vc conseguiu transformar aquele exemplo anemico em um modelo rico, se vc puder passar mais detalhes talves eu possa tranformar o meu modelo em um modelo rico tb, o que pra ser sincero acho dificil.

Creio que a melhor explicação para o que esta acontecendo esta definido abaixo

[quote=sergiotaborda]
O que está em causa é a definição de "metodos de manipulação"
Num DTO esses métodos são getters e setters. Em DDD esses métodos seriam ,além dos getters e setters, getGroup():Group, login() , sei lá… métodos do dominio.
O que está sendo usado pelo colega é só a parte de get/set. Então isso é um TO já que não contem métodos de negocio. Esses estão em outros objetos “de serviço” como aquele “UsuarioLogic” do exemplo.
Este paradigma (TO+Serviço) é incompativel com o paradigma de Entidades e o DDD ? Essa é a questão. A resposta é sim.
E a pergunta é: Então como implementar DDD sem TO nem serviços como UsuárioLogic.[/quote]

#50

Ronildo, quando você estiver menos nervoso releia o que eu escrevi. Neste temperamento eu recomendo que você se acalme porque qualquer coisa postada aqui será infrutífera.

#51

[quote=pcalcado][quote=ronildobraga]
…
[/quote]

Ronildo, quando você estiver menos nervoso releia o que eu escrevi. Neste temperamento eu recomendo que você se acalme porque qualquer coisa postada aqui será infrutífera.[/quote]
Olha… agora eu estou nervoso… #$%^%^&^&&* :x :x :x :x :x :x :x :x :x :x :x :x :x :x :x :x

#52

Mas em lugar algum eu disse que transformei. Não transformei!

Aquele é um exemplo muito simples. Não há comportamento ou lógica alguma. Por isso o Usuario não tem nada além de getters e setters. Mas se tivesse é nele que eu colocaria, e não na UsuarioLogic.

Ter alguma classe de “serviço” como vocês estão chamando (pessoalmente, não gosto desse nome) não impossibilita aplicar DDD e não implica em um modelo anêmico.

As classes de “serviço” geralmente servem para englobar um caso de uso, uma interação entre os objetos. Não é ela que deve ter a responsabilidade das entidades do domínio. Em outras palavras, a UsuarioLogic do exemplo não deve servir apenas para ficar fazendo operações em objetos burros.

Na maior parte das vezes, essas classes de “serviço” apenas mandam mensagens (chamam métodos) para os objetos certos fazerem seu trabalho e realizarem alguma tarefa em conjunto.

#53

Vamos pensar por agora que o sistema corre numa unica JVM e num unico contexto.

Neste caso a resposta ao problema já foi dada.

É isso ai. Existe uma só classe , que representa a entidade e contém todos os get/set e todos os métodos de dominio pretinentes.

Pensemos agora que a classe tem um método login().
Quem chama este método ? Essa classe pertence a que camada ?
Não seria essa classe uma classe de serviço ? Concerteza seria.
Só que ela está em outra camada e pode usar os objetos do domínio como entender.

Mas isto e apenas uma troca de nomes e conceitos. No fim, existirão classes de dominio como Usuário e classe que fazem alguma coisa como os serviços. Além dessas teremos os DAO e afins para persistência.
No fim não ha grande vantagem em ter este modelo, excepto que é mais bonito do ponto de vista de OO.

Usuário não é na realidade um objeto do dominio, a menos que a aplicação seja apenas para autenticação e autorização. Ou, colocando de outra forma, Usuário pertence a um dominio e Cliente (por exemplo) a outro

#54

[quote=ronildobraga]
Tudo bem, entao entendemos que o VO e o BO deve ser descartado e virar uma coisa só, pois o BO é dependente do VO como diz no artigo, mas sinceramente nao vejo como fazer isso, pois os VOs representam os meus registros no banco de dados, e eu nao vou amarrar logica aos meus registros… ou pelo menos nao acho isso muito correto.

So para adiantar, creio que vc deva sugerir usar um POJO para representar os registros no banco de dados.
Portanto teriamos a entidade Usuario e o POJO usuario ? nao vejo muito sentido nisso, pois pra mim um POJO nao é nada mais que um VO.[/quote]

Tente esquecer do Banco de Dados por 1 momento…
Se suas classes todas estivessem na memória…

Objetos devem ter estado e comportamentos… Isso é modelagem Orientada a Objetos certo?

Imagine um JOGO…

Um personagem tem atributos e comportamentos… Modelando isso você teria um objeto com propriedades e métodos…

É tudo a mesma coisa… um Objeto…

A questão aqui é que todos querem enfatizar que modelar de uma forma não anêmica pode trazer benefícios…

Você pode fazer seus sistemas com VOs e BOs e ta tudo certo… O problema é que esse modelo foi encorajado por causa da spec EJB anterior a 3.0 onde teoricamente as logicas estariam em EJBs (BOs) em um ambiente distribuido… e os VOs encapsulariam os dados que iriam trafegar na rede dos EJBs (BOs) até os clientes (web talvez)

A partir do momento em que tudo está no mesmo ambiente, não há necessidade de usar um UsuarioVO se já existe uma classe Usuário… ai nesse caso VO é classificado como anti-pattern

espero ter ajudado

#55

[quote=felipec][quote=ronildobraga]
Tudo bem, entao entendemos que o VO e o BO deve ser descartado e virar uma coisa só, pois o BO é dependente do VO como diz no artigo, mas sinceramente nao vejo como fazer isso, pois os VOs representam os meus registros no banco de dados, e eu nao vou amarrar logica aos meus registros… ou pelo menos nao acho isso muito correto.

So para adiantar, creio que vc deva sugerir usar um POJO para representar os registros no banco de dados.
Portanto teriamos a entidade Usuario e o POJO usuario ? nao vejo muito sentido nisso, pois pra mim um POJO nao é nada mais que um VO.[/quote]

Tente esquecer do Banco de Dados por 1 momento…
Se suas classes todas estivessem na memória…

Objetos devem ter estado e comportamentos… Isso é modelagem Orientada a Objetos certo?

Imagine um JOGO…

Um personagem tem atributos e comportamentos… Modelando isso você teria um objeto com propriedades e métodos…

É tudo a mesma coisa… um Objeto…

A questão aqui é que todos querem enfatizar que modelar de uma forma não anêmica pode trazer benefícios…

Você pode fazer seus sistemas com VOs e BOs e ta tudo certo… O problema é que esse modelo foi encorajado por causa da spec EJB anterior a 3.0 onde teoricamente as logicas estariam em EJBs (BOs) em um ambiente distribuido… e os VOs encapsulariam os dados que iriam trafegar na rede dos EJBs (BOs) até os clientes (web talvez)

A partir do momento em que tudo está no mesmo ambiente, não há necessidade de usar um UsuarioVO se já existe uma classe Usuário… ai nesse caso VO é classificado como anti-pattern

espero ter ajudado[/quote]

Como eu não tenho muuuuitos anos de experiência, eu não tava presente no começo quando surgiu esssa história de BO e VO, mas acho que a Sun deve ter pisado na bola feio pra esse negócio estar errado, mas mesmo assim ser tão usado.

Eu trabalhei em 5 projetos. Os 5 usavam esse conceito de BO e VO, e nenhum usava EJB. Eu sinceramente nunca vi um sistema sem eles. Descobri que estava errado quando li o artigo do Shoes, dai que fui atrás pra pesquisar. E to tentando evitar mais um projeto usando BO e VO nesse que eu to agora, que eu to tendo oportunidade de palpitar na arquitetura…mas tah dificil…pq é um conceito que está arraigado no pessoal…uma praga! hehehe

O problema principal que eu vejo pra isso é o q jah foi citado aqui. O Banco De Dados é o grande vilão! :lol: O pessoal não consegue pensar no sistema sem pensar nas malditas tabelas…hehehe

#56

Na realidade, o pessoal deveria parar de pensar nas malditas classes e pensar mais nas malditas mensagens.

#57

Amém.

#58

So para finalizar… existe um outro post nesse mesmo forum que retrata o mesmo assunto
http://www.guj.com.br/posts/list/45/55388.java

Eu estou procurando entender e solucionar o problema atraves dos artigos e dezenas de materiais existentes na internet… se vc esta na mesma situação que eu e tb tem duvidas sobre como resolver o modelo anemico… sugiro que leia os posts acima e procure a sua propria solução.

Obrigado a todos os interessados que procuram resolver o problema.

******* Editado ************
Se vc ainda nao achou a solução, acesse esses posts
http://guj.com.br/posts/list/105/60916.java


http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Ao final dessas leituras vc deve entender como evitar o uso de VO e BO, detalhe… é muito simples :wink:

#59