Evitando VOs e BOs

Programação Arquitetura
#21

[quote=nbluis]
Dê uma revisada.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/[/quote]
Eu tenho o livro, depois de ver alguns patterns desse livro, e como o proprio luca disse, esses patterns estao voltados ao problemas que o EJB causam.

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

#22

[quote=pm][quote]
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. [/quote]

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…

#23

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…

#24

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

#25

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:

#26

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

#27

[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]

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

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.

[quote=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.
[/quote]

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

[quote=saviobarr] Conhecimento técnico é muito importante, mas tão importante (ou mais) é a postura profissional.
[/quote]

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.

[quote=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. [/quote]

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.

#28

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??? :wink:

#29

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 :wink:

#30

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

#31

[quote=marcosbrandao][quote=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.
[/quote]
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??? :wink: [/quote]
Eu acho uma excelente ideia.

#32

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

#33

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[/quote]

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

#34

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

#35

[quote=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).
[/quote]
ham ? entidade do dominio que trafega entre camadas !
Eu prefiro a difinição do artigo:
Ao utilizar o modelo de programação inspirado em EJBs, devemos dividir nosso domínio em ?classes de dados? e ?classes de lógica?. As classes de dados recebem um nome terminando em VO (o correto seria utilizar o sufixo TO, mas vamos nos ater ao modo como é utilizado comumente), as classes de lógica em BO. O diagrama abaixo mostra este modelo.

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

#36

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…

#37

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.

#38

[quote]
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? [/quote]

:thumbup:

#39

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.

[quote=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[/quote]
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.

#40

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

[quote=Rafael Nunes]se você notar, isso é uma má prática, é conhecido por Anemic Domain Model
[/quote]
Eu entendi que é uma má pratica, por isso o motivo do topico, so nao entendi a solução.

[quote=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.[/quote]
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.