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.
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.
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…
[quote=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 ? [/quote]
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.
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.
[quote=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 ?[/quote]
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.
[quote=Luca]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.
[/quote]
Até hoje me sinto uma besta quadrada quando olho para aquelas coisas.
Acho que devemos ressaltar.
[size=24]A complexidade diminuiu muito.
[/size][size=18] [/size]
Se pudesse eu aumentava mais a fonte.
[quote=pm]
Pra que utilizar VO, BO, TOs e afins em apliçações não distribuidas ?[/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=pm]
simples virar o inferno, utilizando milhoes de patterns… .pra q ?[/quote]
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
[quote=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… [/quote]
Eu tb acho, mas eu achei o artigo muito critico e sem muita solução.
[quote=ronildobraga]
Eu tb acho, mas eu achei o artigo muito critico e sem muita solução.[/quote]
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.
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.
[quote=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[/quote]
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
[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 < 2
hehehehehe…
[quote]
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 [/quote]
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
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”.
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 ?