Evitando VOs e BOs

Ola.
Este final de semana eu estava lendo o seguinte artigo
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

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 ?

O artigo faz referencias a outros artigos sobre o mesmo assunto, por isso aconselho ler antes de qualquer comentário.

Obs.: O artigo foi escrito por Phillip Calçado

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

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 438 Offline

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

ronildobraga wrote:Afinal, o que existe de errado em usar VO, DTO, TO e BO?

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

pcalcado wrote:não há porque utilizar TOs dentro de uma aplicação que não utilize chamadas remotas.

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

Wikipedia wrote:
Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos.

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 wrote: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 < 3.0 há um monte de projetos fracassados por aí. A complexidade diminuiu muito.

Sorte de quem nunca precisou estudar EJBs < 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 wrote:Olá
Sorte de quem nunca precisou estudar EJBs < 3.0. Eu comecei estudando a primeira versão e na época, me senti uma besta quadrada no meio de tanta complexidade.

Até hoje me sinto uma besta quadrada quando olho para aquelas coisas.

Acho que devemos ressaltar.
A complexidade diminuiu muito.

Se pudesse eu aumentava mais a fonte.

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

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.

pm wrote:
simples virar o inferno, utilizando milhoes de patterns.. .pra q ?

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

pm wrote:
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 tb acho, mas eu achei o artigo muito critico e sem muita solução.

Olá

ronildobraga wrote:
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:

Evitando VOs e BOs wrote:"Você pode escrever FORTRAN utilizando qualquer linguagem".

É 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

Luca wrote:
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

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

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