Qual a diferença entre eles
JavaBean X VO(DTO bla bla bla)
?
http://www.portalwebmobile.com.br/java/02.asp
Esta daí é a de JavaBean.
http://koders.com/java/fidF457A8FE527F7E799EA579949C143945C1949CE3.aspx?s=iso+3166
VO em java!!!
De uma olhada e depois me fale se foi o que vc estava procurando!!!
Uma busca neste fórum vai te trazer muitos resultados, só vou consolidar aqui apra evitar que esta pergunta apareça nos próximos meses novamente.
JavaBean -> Modelo de componentes em Java
VO (atual) -> ValueObject, objeto sem identidade que representa um valor como moeda ou data
TO (antigo VO J2EE Patterns) -> Objeto utilizado apra transportar dados entre EJBs
DTO -> Objeto utilizado aot ransprotar dados entre duas camadas físicas (chamadas remotas via webservices, rmi, etc.)
Num sistema normal você geralmente deve utilizar apenas a convenção JavaBeans apra get/set, para manter compatibilidade. Utilizar TO ou DTO é só apra um desenvolvedor que entende muito bem estes dois.
Ah, e se seu sistema for dividido entre classes usuarioVO e usuarioBO, apague o diretorio de fontes e comece de novo. Brincadeira, mas basicamente voce deveria ter apenas uma classe, nao duas, isso não é OO.
[quote=pcalcado]
Ah, e se seu sistema for dividido entre classes usuarioVO e usuarioBO, apague o diretorio de fontes e comece de novo. Brincadeira, mas basicamente voce deveria ter apenas uma classe, nao duas, isso não é OO.[/quote]
Calçado, você poderia ser mais claro?.
Porque o BO(“Business Object”) com o VO(“Value Object”) nao poderia estar em classes diferentes… ???.
Com o VO poderiamos trabalhar como o Um Bean correto?. vc esta se referindo em colocar todo meu Business no Value Object???
Fico no aguardo!.
Er… a premissa da OO nao era colocar os dados e os comportamentos relacionados a eles proximos uns dos outros?
Se sim, pra que caralhos vc vai separar os dados e comportamento em VO e BO?
entao no caso só é interessante separar o business do bean quando é um JAVABEAN … quando é um VO é interessante trabalhar tudo juntos … essa seria a ideia?
-
Releia os posts, ninguém falou isso que você disse.
-
Esqueça diabos de VO, BO, etc. O que você terá são objetos que contém os dados que o representam e métodos para definir o seu comportamento. E só.
-
Dá uma lida nesse artigo do Phillip: http://fragmental.com.br/wiki/index.php?title=Fantoches
-
Releia os posts, ninguém falou isso que você disse.
-
Esqueça diabos de VO, BO, etc. O que você terá são objetos que contém os dados que o representam e métodos para definir o seu comportamento. E só.
-
Dá uma lida nesse artigo do Phillip: http://fragmental.com.br/wiki/index.php?title=Fantoches[/quote]
Daivid se não estou sendo claro me perdoe… mais não perdou quem se faz de cego… a duvida é bastante simples e direta ao assunto!.
MINHA DUVIDA:
Regra de negocio se mistura ao VO sim ou não!??!?!?!?!?
se sim:
- Então não existe BO’s, deletar eles…
se não
- Vamos separar a p*** toda e deixar os VOS sem nenhuma lógica…
Me referi ao JAVABEAN(aquele dos get e sets … :roll: ) pelo simples fato de tentar abstrair a idéia de nosso amigo Calçado!.
Fico no aguardo para discutirmos sobre!
E o que eu, o Philip e o CV falamos é que não deve existir essa separação não importando o nome que você dê àquilo que você está programando, porque na orientação a objetos, estes devem ter dados e comportamento, portanto não faz sentido separá-los em classes distintas. Não importa se você tá chamando o seu objeto de VO, de JavaBean, etc.
Respondendo mais diretamente a sua dúvida: sim, portanto pode apagar os BOs.
[quote=David]E o que eu, o Philip e o CV falamos é que não deve existir essa separação não importando o nome que você dê àquilo que você está programando, porque na orientação a objetos, estes devem ter dados e comportamento, portanto não faz sentido separá-los em classes distintas. Não importa se você tá chamando o seu objeto de VO, de JavaBean, etc.
Respondendo mais diretamente a sua dúvida: sim, portanto pode apagar os BOs.[/quote]
David, finalizando sua idéia cara… (Inclusive muito obrigado pela atenção!),
E oque vc me diz dos JavaBeans com lógica de negócios misturados??, vc esta praticamente me dizendo que seria o correto… seria isso mesmo?
Sim. Dê uma olhada naquele artigo do Phillip que eu postei acima que ele explica direitinho. A idéia básica é: objetos que contém apenas dados e getters/setters são objetos burros, que levam a coisas como repetição desnecessária de código, programação altamente procedural (em oposição aos princípios da orientação a objetos), má divisão de responsabilidades, etc.
mto interessante o artigo… voltei a pensar como aluno iniciante, onde o objeto Aluno possui o metodo salvarNoBancoDeDados().
achei tao interessante quando se deixa o objeto burro armazenando dados, o BO manipulando os dados, o DAO enviando esses dados ao BD, e o RMI recebendo o objeto e identificando o tipo corretamente na outra ponta.
eh isso mesmo que eu entendi?
[]'s
[quote=MaC_Na]eh isso mesmo que eu entendi?[/quote]Se você tiver entendido que os objetos burros guardando dados e outros objetos os manipulando é uma abordagem ruim e que vai de encontro aos principios da programação orientada a objetos, então você entendeu certo. Mas se você tiver entendido que esse é o caminho certo, então sugiro que leia novamente o artigo.
Velho, muito obrigado pela força … agora entendi o contexto explicado por vc ficou bastante claro!. agora misturar a regra de negócio do bean na mesma classe do bean, vai contra oque tenho visto atualmente :shock: … mais de qualquer forma estamos ai para se padronizar com os novos conceitos…
tenho abaixo um classe Pessoa no “método novo” vamos ver:
public class Pessoa {
public String nome;
public String getNome() {
return nome;
}
public void setNome(String nome) {
DAO dao = new DAO();
//Valida nome se é diferente de Jão e se contem mais de 5
if( "jão".equals( dao.findByNome() ) &&
nome.length >5
){
this.nome = nome;
}
}
}
Então essas duas validações do get “nesse contexto” devem estar junto com a propriedade deste bean. certinho entao?
valeu amigo!
Engraçado que o ‘método novo’ é simplesmente o que você deveria fazer com OO desde o início 
Esta confusão começou porque alguém queria usar linguagens OO sem aprender OO e foi passando a tradição de continuar com programação estruturada. De uma maneira geral: classes VO/BO indicam um modelo muito ruim!
Agora, não pense em persistência num primeiro momento. Pense em métodos de negócio.
Depois, para persistência, dê uma olhada na MundoJava #15.
[quote=javaman00]mais de qualquer forma estamos ai para se padronizar com os novos conceitos…[/quote]Como o Phillip falou, na verdade não são novos conceitos, são os conceitos originais da orientação a objetos e que infelizmente foram distorcidos por algumas pessoas.
PS: as tags (code,quote) nao estavam funcionando, testei no FF e no IECA estranho!
Fala pessoal, David e Calçado, descupe a demora da resposta deste tópico é que esta formando uma opinião… para assim podermos encerrar essa discussão tão produtiva!, de forma produtiva. Muito obrigado aos amigos por compartilhar seus conhecimentos.
Calçado:
Esta confusão começou porque alguém queria usar linguagens OO sem aprender OO e foi passando a tradição de continuar com programação estruturada. De uma maneira geral: classes VO/BO indicam um modelo muito ruim!
Sim, entendi agora qual seria o conceito principal em do porque “deixar juntos” o tal do BO.
E ficou muito claro o artigo seu na revista mundo java numero 15 quando você fala sobre:
Toda lógica de negócios é realizada por objetos que colaboram entre si para atingir um objetivo.
E isso descreve bem o Pattern/Conceito “Domain Model”
[b][i]
Calçado:
Agora, não pense em persistência num primeiro momento. Pense em métodos de negócio.
Depois, para persistência, dê uma olhada na MundoJava #15.
[/b][/i]
Enquanto ao pensar em primeiro momento em métodos de negócio, refletiria o exemplo do “jão” que mostrei a pouco neste tópico… correto?, beleza e a persistência como ficaria nesse “contexto” ?, segue minhas dúvidas:
Então ai vem as perguntas:
1)Se esta correta a idéia que tenho sobre persistência “nesse contexto”, seria esse mesmo “modelo de beans” que fará a persistência de meus dados?, quando em meus DAO’s for pegar um pessoa.getNome(); onde antes de persistir os dados terá que passar pelas regras de negocio para essa propriedade desse objeto.
2)Não carregaria minha aplicação visto que irá passar sempre pelas as mesmas regras, sendo que por um lado garanto sempre 100% a integridade do dado persistido?.
3)Continuando nesse contexto… sempre então estaria executando “essas mesmas regras” quando pegar os dados do usuario e quando eu for persistir… correto?
4)Não seria ideal manter então os beans no no modelo burro pelo fato de não ter que utilizar as regras de negócio sempre?.
É muita viagem? :roll:
Fiz um grande estudo quando vi que realmente esta errado o tal de BO e a idéia aqui é fecharmos essa idéia para que então acabemos com a moda do VO E BO =D
Fico no aguardo!
Oi,
Não entendi muito bem o que você quis dizer neste parágrafo.
De qualquer maneira, a idéia é que os objetos de negócio executam as regras de negócio, os DAOs apenas salvam o resultado final no banco de dados e os trazemd e volta em consultas.
Realmente não entendi estas frases, pode reformular?
PS: continua nao funcionando meu “quote” e “code” que coisa :?
[b][i]Calçado:
Não entendi muito bem o que você quis dizer neste parágrafo.
De qualquer maneira, a idéia é que os objetos de negócio executam as regras de negócio, os DAOs apenas salvam o resultado final no banco de dados e os trazemd e volta em consultas.
[/i][/b]
Minhas questões anteriores são referente a esse processo aqui:
os DAOs apenas salvam o resultado final no banco de dados e os trazemd e volta em consultas.
esse resultado final que não consigo montar em minha cabeça como ficaria na prática… visto que sempre usei “BEANS BURROS”, os famosos get e set, no qual uso para trazer os dados no mundo OO para persistir via DAO no mundo relacional…
Minha duvida é a seguinte… eu usuaria o mesmo bean desse novo contexto para persistir os dados no banco ?.
sera que fui claro Calçado? :? desculpe se não fui claro… e valeu pela atenção ae cara!
Olá
As tags precisam ser abertas e fechadas. Experimente sem clicar lá em cima. Escreva a tag na mão dentro dos colchetes e colocando a barra na tag que fecha.
[]s
Luca