Evitando VOs e BOs

Na verdade a solução descrita fala sobre Modelo de Domínio.

Acho que o próprio phillip pode responder isso a você, pois ele é postador do GUJ.

Leia também:http://fragmental.com.br/wiki/index.php?title=Fantoches

O que se fala no artigo sobre EJBs é que sua versão 3 finalmente possibilita uma modelagem rica, sem utilização de VOs, BOs e todas essa demais siglas aí que se vê pela comunidade para descrever objetos que não sabem por que existem.

Amigo, seja um pouco mais crítico ao ler artigos do Philip Calçado. Em todos os artigos ele fala mal de tudo. Até no site da empresa dele (Fragmental) ele vende um serviço de “auditoria” de código, que no meu ver é dizer que o que está implementado está errado e que vale o que ele disser. Que tal se fizermos esse questionamento que você fez diretamente pra ele? Conhecimento técnico é muito importante, mas tão importante (ou mais) é a postura profissional. Arquitetos que dizem que o que está sendo usado é uma droga e deveria ter sido escrito de outra forma (algumas vezes sem conhecer o negócio) o mercado está cheio. O que faz a diferença é entender porque algo foi feito de tal forma e propor uma solução “aderente” para melhorar, antes de criticar. Arquiteto é antes de tudo um questionador, um observador. Lembro que o escrito por mim reflete minha modesta opinião e não deve ser tida como regra.

Bom;

Acho que criticar não resolve problemas, principalmente alguém que já provou seu conhecimento por onde passou e que tem muito a nos oferecer.

Também não estou aqui para defender ninguém, muito menos ideologia.

Mas o DDD é difundido no mundo inteiro, e estudado por grandes mentes do OO.

Agora embase suas afirmativas quanto a defesa de seus BOs e VOs.

Estamos aqui para discutir opiniões

Não sou nenhum arquiteto…

Mas o que vejo muito por ae, é a utilização de patterns em situações bem diferentes do que foram inicialmente propostos.

Pra que utilizar VO, BO, TOs e afins em apliçações não distribuidas ?
Trabalhei em projetos que eram simplismente uma “casca” para sistemas CICS, COBOl…+ simples impossivel… ae os “Arquitetos” fizeram o simples virar o inferno, utilizando milhoes de patterns… .pra q ?

Acho que primeiro vc deveria conhecer seu problema, depois conhecer mto bem os patterns antes de sair implementando !

Putz…acho o Philip Calçado um grande conhecedor de OO e arquitetura… e nunca vi ele defender alguma ideia sem o minimo de embasamento tecnico…

Eu nao tenho conhecimento para defender o uso de BO e VO, porem gostaria de saber quando escolher entre uma e outra solução.

Ao meu ver o Philip descreveu que EJB quase nunca deve ser usado, veja o topico “Quando Tudo Já Está Ruim” do artigo.

Porem ao final do artigo ele fala que EJB seria a solução para os problemas devido a nova especificacão EJB3.

Não vejo alterações dramasticas a esse ponto relacionado ao EJB, parece que ele fala de tecnologias diferentes quando se usa EJB2.1 e EJB3.0

O que se faz com EJB3.0 nao poderia ser feito com EJB2.1 ?

Olá

ronildobraga:

Creio que o artigo descreve como devemos evitar o uso de VO e BO, porem eu achei confuso o artigo pois creio que a solução seria implementar EJB ao seu projeto, mas o artigo mesmo descreve que EJB foi interpretado de forma errado e que EJB é a solução para pequenos problemas.

Afinal, o que existe de errado em usar VO, DTO, TO e BO ? Deveriamos substituir isso por EJB ?

Algumas observações:
1) Há que diferenciar BASTANTE os EJBs anteriores ao 3.0 e os EJBs 3.0
Para mim, os antigos EJBs foram uma das piores coisas inventadas no mundo de TI nestes 38 anos que convivo na área. O projeto nasceu errado, viola princípios básicos de OO com a separação EntityBean/SessionBean e criou uma solução talhada para sistemas gigantes que quizeram empurrar ao mercado como se servisse para tudo.

Para tentar ajeitar os problemas criados pelos EJBs, surgiram diversos design patterns como BO, VO/DTP e muitos daqueles do famoso livro Core J2EE Patterns.

Com a própria evolução dos, com perdão da má palavra EJBs, alguns dos design patterns perderam utilidade. É o caso do uso de EJBs com interface local que não precisavam mais de VO/DTO.

Agora, com os EJBs 3.0, não é mais necessário usar uma arquitetura tão complexa lotada de objetos intermediários que visavam resolver problemas que não existem mais.

2) Os EJBs antigos eram soluções para um pequeno número de problemas
Eles foram criados para aplicações distribuídas e houve um claro abuso pois foi usado em tudo quanto é canto.

3) Deveriamos substituir isso por EJB ?
Usando EJB 3.0 ou apenas JPA/Hibernate, não há mais necessidade de usá-los. O problema é que a maior parte dos artigos escritos são antigos e ainda há muita gente usando DAO+DTO a toa.

[]s
Luca

Nada de errado em usar VO, DTO ou TO pelo motivo certo. O problema é que muita gente usa um todas as situações.

Quanto a BO, é simplesmente pra programar OO direito. O que deixa as coisas muito mais fáceis.

Ou seja, uma classe de nogócio alia dado e comportamento, então não é uma boa prática de OO criar um POJO burro, só com atributos, e uma classe BO com o comportamento.

[]'s

Rodrigo Auler

Olá

ronildobraga:

Não vejo alterações dramasticas a esse ponto relacionado ao EJB, parece que ele fala de tecnologias diferentes quando se usa EJB2.1 e EJB3.0

O que se faz com EJB3.0 nao poderia ser feito com EJB2.1 ?

A confusão foi criada pela SUN. Ela não deveria ter mantido o nome EJB para a nova especificação.

A grande diferença é que com EJB 3.0 você tem boas chances do seu projeto dar certo enquanto com EJBs &lt 3.0 há um monte de projetos fracassados por aí. A complexidade diminuiu muito.

Sorte de quem nunca precisou estudar EJBs &lt 3.0. Eu comecei estudando a primeira versão e na época, me senti uma besta quadrada no meio de tanta complexidade.

[]s
Luca

Luca:

Olá
Sorte de quem nunca precisou estudar EJBs &lt 3.0. Eu comecei estudando a primeira versão e na época, me senti uma besta quadrada no meio de tanta complexidade.

Acho que devemos ressaltar.
[size=24]A complexidade diminuiu muito.
[/size][size=18] [/size]
Se pudesse eu aumentava mais a fonte.

pm:

Pra que utilizar VO, BO, TOs e afins em apliçações não distribuidas ?

pm:

simples virar o inferno, utilizando milhoes de patterns… .pra q ?

pm:

Putz…acho o Philip Calçado um grande conhecedor de OO e arquitetura… e nunca vi ele defender alguma ideia sem o minimo de embasamento tecnico…

Olá

ronildobraga:

Eu tb acho, mas eu achei o artigo muito critico e sem muita solução.

Pode ser que esteja um pouco confuso devido à própria complexidade dos EJBs mas a mensagem principal acho que está clara: Evite os patterns que foram criados em um mundo mais confuso do que o atual.

Sem querer fugir do assunto do tópico mas já fugindo, o único erro do artigo é a afirmação:

É errado pois não se pode escrever Fortran com Java. Pelo menos enquanto Java não possuir tipos numéricos tão bons e tão eficientes como Fortran para o trato de grandezas do mundo dos números reais.

[]s
Luca

Ok… entendi.
Vc pode passar alguns artigos iniciais para aprender EJB3, JPA ?
Eu procurei no google e achei alguns, mas gostaria de saber se vc tem um especifico que possa indicar.

Luca:

Pode ser que esteja um pouco confuso devido à própria complexidade dos EJBs mas a mensagem principal acho que está clara: Evite os patterns que foram criados em um mundo mais confuso do que o atual.
[]s
Luca

A mensagem que ele queria dizer para mim estava clara, ou seja, nao use VOs e BOs, porem eu nao sabia porque e nem como resolver, agora esta claro. Obrigado

Olá

Tenho os 3 livros abaixo e recomendo:

Java Persistence with Hibernate

Enterprise JavaBeans 3.0 (5th Edition)

Pro EJB 3: Java Persistence API

No google você achará muita coisa. Mas eu ainda gosto dos livros.

[]s
Luca

Em aplicações nao distribuidas o EJB deve ser descartado, correto ? e para suplantar o EJB nessas situações foram criados alguns pattens para essas aplicações.

ae…tavendo a confusão ! Os patterns não tem nda a ver com o q vc falou! Os patterns(da sun EE) foram criados como remendo para a porcaria do EJB &lt 2

hehehehehe…

Confesso que a minha aplicaçõa esta confusa mesmo, porem se nao usasse esses patterns acho que as coisas seriam mais complicadas ainda, pois agora eu tenho um padrao onde todo mundo saber usar, ao inves de implementar uma solução nao comumente usada.
Vc pode ver a minha abordagem dos patterns DAO, DTO e BO em www.iprogramming.blogspot.com

Em nenhum momento eu falei pra naum usar patterns… mas sim usar de
forma coerente… sem atacar produtividade e clareza do codigo !

cara…eu trabalho com dois sistemas muito simples, muito mesmo…os dois possuem VOs e ainda uma camada POJO… pra q ? Alias utiliza JSF+hibernate… basicamente CRUD…e ainda pergunto, o que possou pela cabeça do cara que projetou isso … usando VO ?

Em vez de ter 200 classes… o sistema teria umas 70… mas seria complicado ! melhor implementar interfaces, camadas burras, meter 500 linhas de codigo num BC e dizer pra td mundo que eu usei patterns

Luca;

Concordo sim com sua afirmação.
Mas defendo o que está escrito no artigo;

O fato não é se uma tecnologia abrange totalmente outra.
Se analisar o contexto ao qual foi falado, verás que é uma afirmação é indicada diretamente a programação orientada a objetos, e aqueles que “acham que por que programam classes ao invés de units, programam orientado a objetos”.

PS:Gostei do andamento do tópico;

Olá

Só escrevi aquilo para provocar o Phillip… :lol:

Na verdade entendi como vcê o que ele quiz dizer com a frase.

[]s
Luca

Se eu nao me engano, o proprio Fowler faz uso desses patterns em aplicações que não usam EJB. E existe diversos artigos sobre esses patterns descrevendo como eles devem ser usados.

Hoje entendemos que misturamos alhos com bugalhos ao usar esse patterns fora de um contexto EJB, porem eu acho que na verdade eles so entraram em desuso pois os problemas que eles resolviam ja nao existem mais.

EJB 3 nao possui tantos problemas, por isso nao deve ser usado tais patterns, e esses patterns nao devem ser usados fora de um contexo EJB, pois os problemas que existiam no EJB nao existem em aplicação baseadas em Servlets.

Agora eu me pergunto, porque aplicaram os patterns para EJB em aplicações baseadas em Servlets ?

*editado
patterns de EJB - patterns para EJB

Patterns de EJB?
Core J2EE Patterns são para EJBs?
Dê uma revisada.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/

nbluis:

Dê uma revisada.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/

Logico… eu nao falo de todos, estamos falando sobre os patterns VO e BO abordados no livro, mesmo que ele aborde outros patterns relacionado a EJB, alguns patterns desse livro servem para um contexto fora do EJB, mas creio que nao seja esses que estamos discutindo

pm:

Em aplicações nao distribuidas o EJB deve ser descartado, correto ? e para suplantar o EJB nessas situações foram criados alguns pattens para essas aplicações.

ae…tavendo a confusão ! Os patterns não tem nda a ver com o q vc falou! Os patterns(da sun EE) foram criados como remendo para a porcaria do EJB &lt 2

hehehehehe…

O que você considera “usar de forma coerente”? Seria seguir o cook book Core J2EE Patterns? Assim, eu não vejo outra forma de usar patterns se não for seguindo o que está escrito no Core J2EE Patterns…

Aproveitando: qual a diferença entre VO e DTO? Há alguma situação em que é elegível usar os 2 num mesmo sistema? Eu peguei um sistema em que a arquitetura usa VO + DTO + Form Bean normal. Alguma situação justifica o uso desses 3 elementos? Eu sempre encarei o VO e DTO como sendo quase a mesma coisa…

Olá

No contexto deste tópico não há diferença entre VO e DTO. O Value Object do Core J2EE patterns depois mudou de nome para DTO. Ambos serviam para carregar dados de uma camada para outra. Veja http://en.wikipedia.org/wiki/Value_Objects

Pode ser que seu sistema tenha passado por vários desenvolvedores e cada um usou um codinome diferente.

Mas a sigla VO também é usada para outro pattern bastante comum e bem mais simples, também chamado de Value Object. Veja http://www.martinfowler.com/bliki/ValueObject.html

[]s
Luca

usar de forma coerente é no minimo saber porque vc esta usando tal pattern! e não so porque viu numa revista !

Exemplo claro é a utilização de VO em tudo que é projeto. Ate em exercicios pra exibir numeros pares de 0 a 100 ja tem VO implementado ! :lol:

A questão é.
Qual a utilidade de VOs nos tempos de hoje?
Mesmo transferindo entre camadas.

[color=red] [size=18] Nota: Considere este post um direito de resposta. Este assunto não será tratado neste fórum ou nesta thread, mensagens devem ser trocadas entre os envolvidos via PM, e-mail ou o que for[/size][/color]

saviobarr:

Amigo, seja um pouco mais crítico ao ler artigos do Philip Calçado.
Em todos os artigos ele fala mal de tudo.

Por favor! E sabe do que mais? Por favor me mandem suas críticas, sugestões, feedbacks e ameaças de morte por e-mail ou deixem um comentário. Ou um trackback.

saviobarr:

Até no site da empresa dele (Fragmental) ele vende um serviço de “auditoria” de código, que no meu ver é dizer que o que está implementado está errado e que vale o que ele disser.

Que tal se ao invés de especular sobre os serviços que preste você perguntasse sobre eles?

saviobarr:

Conhecimento técnico é muito importante, mas tão importante (ou mais) é a postura profissional.

E qual seu ponto sobre minha postura profissional? COm esse bashing gratuito num fórum público acho que você não está no papel de questioná-la, mas caso sejam críticas construtivas gostaria sim de ouví-las.

saviobarr:

Arquitetos que dizem que o que está sendo usado é uma droga e deveria ter sido escrito de outra forma (algumas vezes sem conhecer o negócio) o mercado está cheio. O que faz a diferença é entender porque algo foi feito de tal forma e propor uma solução “aderente” para melhorar, antes de criticar. Arquiteto é antes de tudo um questionador, um observador. Lembro que o escrito por mim reflete minha modesta opinião e não deve ser tida como regra.

Ora bolas, confuso isso. Parece que você ficou irritado com minha postura de questionar e comentar negativamente o status quo, agora você diz que não sou questionador? Tanto no artigo que originou o tópico quanto em todos os outros eu cito vantagens e desvantagens das coisas, além de provêr alternativas. Nãoe stá satisfeito? O bom Zahl inventou o botão de ‘fechar’ para estas situações.

Agora seria legal se você desse alternativas aos meus textos, em vez de ficar simplesmente criticando, não?

Veja só que interessante, eu tenho um artigo que comenta esta diferença com bastante ênfase e ele se chama “Evitando VOs e BOs”.

Bashing gratuito, CQD. Tudo bem, acontece. Agora vamos ás mensagens que interessam de fato.

Que tal algum fera do guj escrever e disponibilizar aqui no guj um artigo mais atual e descente, descrevendo de como se usa de maneira correta o EJB 3???

Bom, vamos lá.

O Artigo foi criado para que eu não escrevesse a mesma coisa pela 183823823a vez quando alguém fala que usa BOs e VOs. A alternativa para ele está linkado nas referências e se chama Desenvolvendo Sistemas OO Com Padrões de Negócio. É um artigo da Mundo Java, em breve terei um artigo com o mesmo tema, mais aprofundado.

Modelo Anêmico(BO+TO) ou Domain Model é uma questão de modelagemd e software, que pouco tem a ver comt ecnologia (EJB, Hibernate, Servlets, etc.). Eu posso ter ambos com qualquer tecnologia, é apenas filosofia de design de software.

EJBs (&lt3.0) quase nunca devem ser usados. Existem poucas demandas que uma aplicação pdoe ter (alta concorrência, distribuição, transações distribuídas) que justifiquem seu uso, e mesmo assim com parcimônia. Criar um EJB apra cada classe de engócio é impensável. Mesmo neste cenário, como dito acima, pode-se escolher entre vários modelos, anêmicos ou não.

DTO em si, como o artigo cita, é útil em seud evido lugar, trocando dados onde é custoso. Chamadas de rede, serialização, etc. Dentrod e uma mesma JVM seu uso é altamente excepcional, geralmente quando você precisa de grandes bandos de dados (relatórios, por exemplo) e não de objetos de negócio.

Eu tentei responder os pontos que vi espalhados pelo tópico, se alguém puder condensar as dúvidas restantes em um post só nós continuamos

O seu artigo me deu a entender que não é muito aconselhavel usar BO e VO fora de um contexto de EJB e que eu deveria buscar outra solução.
Com base nisso eu procurei a solução no seu artigo e pensei que a solução seria usar o EJB3, mas como vc dizia no artigo e frizou de novo que EJB é uma solução para poucos problemas entao eu fiquei na duvida de como solucionar o problema para evitar o uso de VO e BO.
Eu achei que o topico tinha sido esclarecido quando o Luca fez suas explicações, porem acho que vc tem uma outra solução que sinceramente nao consigo perceber

Eu entendo que DTO e VO sejam a mesma coisa, no artigo parece que vc enxerga algumas peculiaridades entre um e outro, mas enfim, eu acho sensato usar VO para trafegar dados entre as camadas, por exemplo: Como disponibilizar uma lista de registros de usuarios no banco de dados para o cliente ?

********** Editado *************
Tudo bem… o artigo abaixo explica como evitar BO e VO http://fragmental.com.br/wiki/index.php?title=Desenvolvendo_Sistemas_OO_Com_Padrões_de_Negócio

Obrigado

marcosbrandao:

Luca:

3) Deveriamos substituir isso por EJB ?
Usando EJB 3.0 ou apenas JPA/Hibernate, não há mais necessidade de usá-los. O problema é que a maior parte dos artigos escritos são antigos e ainda há muita gente usando DAO+DTO a toa.

Que tal algum fera do guj escrever e disponibilizar aqui no guj um artigo mais atual e descente, descrevendo de como se usa de maneira correta o EJB 3???

Eu, particularmente, acho bem bizarro usar esta abordagem numa aplicação não-distribuída.
O que exatamente tem de errado em trafegar o próprio objeto Usuário entre as camadas? Você estará trafegando um objeto que faz parte do domínio e possui as propriedade e comportamentos que deve ter. Para que precisa de uma classe alienígena como um DTO que junta uma porção de dados estranhos(praticamente uma struct do C) só para trafegar dentro da mesma VM?

Por exemplo, esta abordagem:
Padrão Repository

Eu, particularmente, acho bem bizarro usar esta abordagem numa aplicação não-distribuída.
O que exatamente tem de errado em trafegar o próprio objeto Usuário entre as camadas? Você estará trafegando um objeto que faz parte do domínio e possui as propriedade e comportamentos que deve ter. Para que precisa de uma classe alienígena como um DTO que junta uma porção de dados estranhos(praticamente uma struct do C) só para trafegar dentro da mesma VM?

Por exemplo, esta abordagem:
Padrão Repository

Mas o Usuario nao seria o proprio VO ?

Mas ao inves de termos servidor e cliente, nos teriamos a camada de persistencia e a camada de apresentação

Não, seu Usuario seria uma entidade do domínio que trafega entre as camadas além de participar do seu modelo.(Estou assumindo que você se refere a VO para um similar a DTO).

Rafael Nunes:

Não, seu Usuario seria uma entidade do domínio que trafega entre as camadas além de participar do seu modelo.(Estou assumindo que você se refere a VO para um similar a DTO).

eu vejo como se fosse o VO também… e por trabalhar com EJB você separou como diz no artigo os dados da lógica…

Então… tenta esquecer um pouco VO e BO e tentar lembrar das aulas de OO básico onde tinhamos objetos com seus dados e suas respectivas operações (métodos).

O que você chama de VO na verdade deveria ser uma entidade. Ao invés de você chamar de AlunoVO chame de Aluno. Então entenda que Aluno seria uma das entidades do seu domínio. O BO também tem que ir para o beleléu. Entidade é mais esperta que VO pois operações e dados caminham juntos… portanto não justifica usar BO’s.

Um VO de acordo com o DDD (veja o livro Domain Driven Design Quickly) não deve possuir id. Se este é o seu caso então o seu VO nunca foi um VO.

Eu, particularmente, acho bem bizarro usar esta abordagem numa aplicação não-distribuída.
O que exatamente tem de errado em trafegar o próprio objeto Usuário entre as camadas? Você estará trafegando um objeto que faz parte do domínio e possui as propriedade e comportamentos que deve ter. Para que precisa de uma classe alienígena como um DTO que junta uma porção de dados estranhos(praticamente uma struct do C) só para trafegar dentro da mesma VM?

:thumbup:

Sim. Um simples objeto Usuario que está na camada de negócios, e é transportada para a camada de cliente. Como no exemplo da primeira imagem que você postou nesta página.

Leia essa parte novamente no artigo, se você notar, isso é uma má prática, é conhecido por Anemic Domain Model, ou Modelo Anêmico.
Um objetos ou os objetos, foram criados para ter estado E comportamento, e não estado OU comportamento. Logo, é um modelo anêmico você ter uma classe UsuarioVO, que seria um objeto burro, sem comportamento, apenas uma estrutura de dados de um usuário. E outra classe UsuarioBO que engloba a lógica de negócio pertinente ao objeto Usuario. Em um modelo rico, você deveria ter tudo que for respectivo ao usuário: dados e lógica de negócio, encapsuladas dentro do objeto Usuario, e não em objetos separados.

ronildobraga:

Ou seja, o que vem a ser a entidade do dominio que trafega entre camadas que vc disse ? Nao seria o proprio VO !? Eu nao vejo porque vc citou isso como bizarro

Desculpa… nao tive aulas do genero… mas estou entendendo assim mesmo… quando eu puder eu procuro as aulas, Obrigado.

Ok, entao estamos de acordo o que vem a ser uma entidade

Rafael Nunes:

se você notar, isso é uma má prática, é conhecido por Anemic Domain Model

Rafael Nunes:

Vem a ser o próprio objeto Usuario, que é a junção do UsuarioVO e UsuarioBO, dados e lógica de negócio.
A parte do ‘bizarro’, foi o fato de ter uma classe para regra de negócio, e uma classe para lógica de negócios.

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.

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!

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.

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.

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ó?

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.

Rafael Nunes:

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.

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.

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.

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.

ronildobraga :

Desculpa… nao tive aulas do genero… mas estou entendendo assim mesmo… quando eu puder eu procuro as aulas, Obrigado.

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.

[quote=ronildobraga]

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.

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”

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

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

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.

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.

pcalcado:

ronildobraga:

…

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.

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.

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

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.

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

felipec:

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.

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

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

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

Amém.

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

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