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 -&gt Modelo de componentes em Java

VO (atual) -&gt ValueObject, objeto sem identidade que representa um valor como moeda ou data

TO (antigo VO J2EE Patterns) -&gt Objeto utilizado apra transportar dados entre EJBs

DTO -&gt 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.

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.

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?

1. Releia os posts, ninguém falou isso que você disse.

2. 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ó.

3. Dá uma lida nesse artigo do Phillip: http://fragmental.com.br/wiki/index.php?title=Fantoches

1. Releia os posts, ninguém falou isso que você disse.

2. 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ó.

3. Dá uma lida nesse artigo do Phillip: http://fragmental.com.br/wiki/index.php?title=Fantoches

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.

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.

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

MaC_Na:

eh isso mesmo que eu entendi?

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.

javaman00:

mais de qualquer forma estamos ai para se padronizar com os novos conceitos…

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

<EDITADO>Acabei de descubrir o problema… na VISUALIZÇÃO quando vc esta criando o texto ele caga… somente quando posta… que da pra ver como fica… testa ae pra vc ver…</EDITADO>

não vai cara … que nem agora mandei “citar” e estou digitando esse texto… olha como ficara abaixo…

Luca:

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

inclusive dei uma lida legal aqui:

http://www.martinfowler.com/eaaCatalog/domainModel.html

Calçado???, ta por ae :roll: vammo finalizar esse assunto!

Sim, o mesmo bean que você usa com os métodos contendo regras de negócio seria usado para persistência no banco de dados. Não há nenhum impedimento com relação a isso, a camada de persistência permanece inalterada.

Mas eu não creio que a sua dúvida seja apenas isso, então acho que não entendi muito bem o que você quis dizer. Se puder explicar melhor…

David:

Sim, o mesmo bean que você usa com os métodos contendo regras de negócio seria usado para persistência no banco de dados. Não há nenhum impedimento com relação a isso, a camada de persistência permanece inalterada.

Mas eu não creio que a sua dúvida seja apenas isso, então acho que não entendi muito bem o que você quis dizer. Se puder explicar melhor…

Fala ae velho beleza?, entao cara acho que vcc ja solucinou minha duvida inclusve fiz um filtro nas questões e vou ser direto no que ainda que me intigra… mais cara se eu estou viajando… paramos por aqui

seguinte…

como vejo muitas pessoas usando beans “simples/burros” ao invés delas com as regras de negocio… isso nao poderia atrasar o sistema de alguma forma quando sempre for fazer esses dois fluxos:

USUARIO(JSP) => BEANXYZ(Com as regras de negocio)

BANCO => DAO => BEANXYZ(Com as regras de negocio)

ao inves de:

USUARIO(JSP) => BEANXYZ(Com as regras de negocio)

BANCO => DAO => BEANXYZ(simples/burro)

OU no famigerado BO rs.:

USUARIO(JSP) => BO => BEANXYZ(simples/burro)

BANCO => DAO => BEANXYZ(simples/burro)

veja que eu ja coloquei a ideia de se utilizar o mesmo bean como manda a “teoria”.

Agora somente minha preocupação foca na velocidade… visto que agora pelo que entendi iremos ser obrigados a executar a regra de negocio 2 vezes num sistema… ao invés de uma…
quando populamos um bean burro/simples vindo do banco sem as regras de negocio… mantendo assim… somente do USUARIO(JSP)=>BO => BEANYXZ, e ai sim passaria pelo tal do famigerado BO :shock:

entendeu minha duvida?

vlw cara

OBS: Deixando claro que nos 3 casos ficaria assim:

(1º Caso)

• 1 Bean com regras de negocio para fazer o leva e tras…

(2º Caso)

• 1 Bean com regras de negocio para validar os dados da tela(alem logico do JS)
• 1 Bean simples/burro

(3º Caso)

• 1 Bean simples burro para ser utilizado pelo leva e tras
• 1 BO para as regras de negocio chamando o assim quando o sistema precisar validar algo… e nao usando no DAO

enquanto ao BO nao estou protegendo… mais estou ilustrando oque atualmente acontece por ai… em meus estudos ficou muito claro esse problemas… e por enquanto ainda me resta interrogacoes…

javaman00:

Agora somente minha preocupação foca na velocidade… visto que agora pelo que entendi iremos ser obrigados a executar a regra de negocio 2 vezes num sistema… ao invés de uma…

http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Nesse modelo, de quem é a responsabilidade de metodos como:

• buscarTodosUsuariosSemGrupo();

Da classe Usuario? Mesmo que as regras desse metodo não tenham nada a ver com o objeto usuário instanciado? (já que o retorno é uma lista de vários usuários)?

É correto em OO o metodo de uma classe Usuario tratar coisas de outros usuários?

Complicando mais ainda, e quando além de buscar os usuários, a regra de negocio é responsável por dar um loop em cada um e setar um flag. Isso não é cenário para um BO? Um lugar onde se possa manipular dados e objetos do tipo Usuario, de acordo com as regras de negócio do sistema.

Ou a classe Usuario deve ser responsável por tratar outros usuários?

questions, questions…

cv:

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?

Desculpe ressucitar o post, mas essa resposta do CV foi perfeita. Tenho concordado muito com o CV ultimamente… estaria eu granhando ares britanicos?

próximo quer dizer um objeto usuario ser responsavel por regras de outros objetos usuario?

setNome() no usuario é próximo

agora alterarTodosUsuariosInativos() é próximo ou invasivo?
a questão é: um Usuário tem a responsabilidade de alterar coisa dos outros?

1. Releia os posts, ninguém falou isso que você disse.

2. 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ó.

3. Dá uma lida nesse artigo do Phillip: http://fragmental.com.br/wiki/index.php?title=Fantoches

Excepcional artigo !!!
Uma das melhores comparações/explicações do jeitão que muitos de nós ainda trabalha “proceduralmente”. Vou imprimir e ler novamente pois ficou muito claro o exemplo.

Parabéns Phillip !

Duas dúvidas:

[list]Dentro do exemplo contido no artigo fantoches(fragmental.com.br/wiki/index.php?title=Fantoches)

Onde ficaria a chamada a um(ou mais) método(s) de persistência para persistir em banco de dados o ato de estacionar, e desocupar vaga?[/list]

[list]Chamadas vindas da persistência (como uma tela de sistema contendo uma listagem de todos os carros estacionados ou todas as vagas ocupadas) seriam uma chamada direta ao DAO da tela? Haveria uma chamada da tela a um método contido no objeto de domínio(carro ou vaga) que por sua vez chamaria a coleção de um DAO correspondente?[/list]

Grato se me tirarem essa dúvida. :?

[]'s

Ola,

Essa dúvida passa de projeto á arquitetura. Sobre arqutietura existem mais dois artigos que podem te responder:
Arquitetura de Camadas em Java EE
Desenvolvendo Sistemas OO Com Padrões de Negócio

Respondendo rapidamente: persistência é responsabilidade de outra Camada.