Dúvida sobre Modelagens de Beans e Padrões

Olá Elias!

O problema é que vc não deve encarar modelagem de classes como se fossem banco de dados!

Imagine que se você fizer o relacionamentos usando ID, você dependerá do banco, sempre que precisar saber que está relacionado com quem!

Já quando você faz um relacionamento, onde os objetos que relacionam contém um ao outro, é só navegar sem problemas entre eles, realizar operações e etc…

Repare que durante a modelagem, vc provavelmente terá métodos que atuarão em cima de objetos no qual se relacionam com ele!

Um exemplo!

Você tem um objeto Sala que contém város objetos alunos!
Agora você precisa colocar um método na classe sala para calcular a média geral da sala!

Se você tiver apenas o Id dos alunos dentro do objeto sala, como vocÊ fará o cáculo da média? Vc será obrigado a acessar o banco! Daí sua modelagem foi pro saco e OO também!

Mas agora, se dentro do objeto sala vc possui objetos do tipo aluno, é só vc varrer todos alunos e chamar o metodo getMedia de cada aluno e dividir pelo número de aluno que tem na sala! Não é mais fácil!!???

É isso ai!
Espero ter ajudado!
Abraços!

hehehe tá começando a esclarecer…

Mas quando sala tem alunos, que tem provas, mensalidades, professores, enfim uma séries de coisas, imagino que os beans ficam enormes. E as vezes não queremos isso tudo, ainda mais que existem as collections que pode ajudar nesse sentido, como vcs encaram isso? Eu programo para Web, usando servlets e jsp.

Deve existir diversos métodos de consulta ao aluno como no seu exemplo, de acordo com as nescessidades?Lembrando que eu disse, o aluno tem provas, mensalidades, professores, contatos e por ai vai…

Você só busca no banco o que você precisa naquele momento oras

Elias…

Um fato importante a considerar é o seguinte!
Cada classe tem suas próprias responsabilidades. Por exemplo, a sala deve saber calcular a média geral da sala, mas cada aluno deve saber calcular a sua prórpia média!!!

Mas no caso que você citou, você deve implementar as classes desta forma independente da quantidade de relacionamentos…

Como o Lipe citou, você acessará o banco e retornará apenas os dados que realmente lhe interessarem para determinada transação do sistema! Se você precisa saber a mensalidade que o aluno vai pagar, então busque no banco os dados do objeto mensalidade e aluno, e deixe de lado os dados referente a sala de aula, professor, boletim e etc!!!

Abraços!

Uma explicação chula, mas vamos lá.

Não significa que você tendo sala, alunos, mensalidades, notas e o que mais estiver relacionado no bean, você tera OBRIGATORIAMENTE de trazer tudo isso sempre.
Voce pode trazer só sala, só aluno, aluno e sala e etc.

Os relacionamentos só servem na hora de tratar esses dados em suas classes, como o Thiago já falou, eles são somente amarrações internas, e não obrigatórias.

Beleza galera, mas qual patern agora mais me caberia bem?

um Factory para consulta do bean aluno?

pois eu teria que criar:

Aluno aluno = aluno.consultaAlunoComBoletim();

ou em determinado momento:

Aluno aluno = aluno.consultaAlunoComMensalidades();

Exemplo:

A página de cadastro teria os dados pessoais, endereco, contatos, sala.

na consulta de mensalidades teria dados pessoais e as mensalidades.

na página de matricula teria sala e professores.

Ou seja eu em determinados momentos eu teria o bean aluno com boletim, mensalidades, endereços, contatos e por ai vai, em diferentes instâncias.

ok?

Elias, não entendi muito o que você está querendo dizer… mas vou tentar esclarecer algumas coisas, caso você não saiba!!!

Se você for iniciante, o primeiro passo é conhecer os EJB Entity Beans!!! OU Hibernate!!

Brincadeira!!! Esquece por enquanto EJB e Hibernate caso você seja iniciante… só foi para brincar, hehe!!!

Você quer saber qual pattern utilizar para fazer a persistência no banco???
Bom, estão vamos lá!

Se você cria uma classe chamada Aluno, você poderá criar uma classe chamada AlunoDAO. Ou seja, você deverá usar o Desgin Pattern Data Acces Object, que é o DAO!

http://www.guj.com.br/posts/list/21017.java
http://www.guj.com.br/posts/list/21007.java
http://www.guj.com.br/posts/list/21002.java

Estes posts acima tem algumas discussões interessante que ocorreu um tempinho atrás, onde tiramos algumas dúvidas sobre DAO e DTO (Data Transfer Object)… Dê uma lida neles que vai te acrescentar bastante! O pessoal durante a discussão colocaram vários links e indicaram outros posts! Fique atento nestes links, que tem vário links preciosissimos!!!

Mas Voltado ao AlunoDAO, ao invés de você ficar criando um método criar, alterar, excluir e consultar ou qualquer outro método que precise acessar o banco utilizando SQL dentro da classe aluno, você deverá colocar dentro da classe AlunoDAO, ao invés de colocar dentro da classe aluno!

Assim, você separo a camada de negócio (Aluno) da camada de Persitência(AlunoDAO).

Se você quiser por exemplo criar um aluno no banco, é só vc chamar o método create do AlunoDAO e passar o objeto Aluno por parâmetro! Daí o dao se responsabiliza em colocar o danado no banco! O mesmo se repete para consultas, exclusões e etc…

Era isso mesmo que você estava procurando???

Acredito que sim, vou utilizar o DAO, agora clareou minha mente um bucadão!!! hehehe. Mas apesar da brincadeira vou estudar mesmo o hibernate… Já comprei tres revistas pra ver se eu aprendo.

Obrigado…

É nessa parte que eu to me enrolando também.

Por exemplo eu tenho uma classe CD, e nela um atributo que é um objeto Musica, e dentro de Musica um atributo que é um objeto Artista.
Quando eu for fazer um session.save(cd), vou primeiro ter de instanciar um objeto Musica e um objeto artista?

Bom, depende!

Se você for salvar apenas o cd, e o cd no momento não contiver músicas e nem artista, blz, não precisa.

Mas se na sua IHM por exemplo o cara deu os dados do cd, das músicas e dos artistas, vc deverá instanciar todos eles.

Imagine o seguinte. Se você tem as classes CD, Musica e Autor, então você deverá term os DAOS CdDAO, MusicaDAO e AutorDAO! Cada um deles se responsabiliza por salvar o seu determinado tipo de dado.

imagine isso…

cdDAO.save(cd);

artistaDAO.save(cd.getArtista());

musicaDAO.save(cd.getMusicas());

tá ai… é meio porquinho, mas é mais ou menos assim!!!

RAfael Nunes…

No exemplo que vc citou do cd, artista e musica acabei interpretando que cada cd tivesse um artista. Mas para exemplificar uma outra situação, imagine que cada música tem um autor!

Daí siga o mesmo passo de sempre, crie um AutorDAO.

Dentro do método

musica.save() pode ocorrer uma chamada ao autorDAO, mais ou menos assim:

autorDAO.save(musica.getAutor());

Também acho isso esquisito, e realmente é…

Mas ainda fica valendo o que muitos já postaram nos posts anteriores. Se na sua transação você não precisa do autor, então não instancie ele… é desnecessário!

O que é errado é vc esquecer das classes de negócios e ficar vivendo de DAO. Se não OO vai pro saco!

Fazendo um questionamento na visão de um leigo.

Porque um DAO para cada classe se meu objeto está relacionado com os outros?
Deveria cdDAO.save(cd) ser capas de gravar o autor, as musicas então

Essa questão de ter um DAO para cada Classe, isso me parece ferir a OO, isso se deve ao fato de estar trabalhando com um banco relacional, certo?

Nos SGDBOO é possível gravar um objeto e seus relacionamentos ou somente Hibernates da vida conseguem?

Skill, sinceramente eu num sei…

Eu costumo fazer assim, um DAO para cada classe de negócio! Sei que a outras maneiras de se fazer DAO, mas até aqui eu só fiz assim!

Quanto ao fato de ferir OO, acho que o DAO não influencia muito, já que ele tem o objetivo de apenar fazer a persistência… O que ele deve garantir talvez seja o fato de garantir que o modelo de negócio possa trabalhar sem se preocupar em como ele será persistido!

Assim, o OO de verdade fica na camada de negócio…
Acho que o problema tá crescendo… será que o Shoes, CV, mister_m ou alguém mais vai ter que interferir nesta conversa???

Abraços!

É por isso que acho Relacional e OO não se bicam.
São estruturas diferentes. Até hoje só tem gambiarra da boa.

É, achei complicada essa modelagem, porque você não vai fazer inserções de artistas e músicas se você não tiver um cd.
Ou seja, eles são atributos de um cd, e só existirão junto com este.

Thiago,

Pensando assim teremos problema ou eu nao entendi nada.

Exemplo de relacionamento.

class DVD{ private int codigoDVD; private String nomeDVD; private Autor autor; private List<Musica> listMusicas; ... } class Autor { private int codigoAutor; private int codigoDVD; private String nomeAutor; .... } class Musica { private int codigoMusica; private int codigoDVD; private String nomeMusica; private int duracaoMusica; ... }

Como tu faz para inserir com teu Dao esse modelo?

.... daoDVD.save(dvd); daoAutor.save(autor); daoMusica(musica);

E assim fica setando os codigos na munheca na camada de negocio?

É isso?

]['s

Boa pergunta… E muito crucial para mim…

Bom… seria sim na munheca!!!

Dependendo da transação eu faria só instaciaria os objetos que são de meu interesse!!!

Mas acredito que se você organizar bém os seus dados, você não precisará ficar fazendo tanta coisa assim na munheca!

Imagine o seguinte. Se você precisa recuperar um DVD com todas suas músicas e o artista, quando então você criar o command, action, Façade, ou seja lá o que for, cada dao conhece o sua classe de negócio.

Então vc chamada o dao DVD que popula os dados do dvd, chamada o dao de Musicas para recuperar todas as musicas referentes à aquele DVD e depois vc chamada o o dao do artista e recupera o artista daquele dvd!

Depois você mexe bém, coloca maizena, unta e coloca no forno!!! rsrsrs…
brincadeirinha!!

É só colocar os dados na casse negócio… até aqui não é tão complicado!

Já quando é o inverso, ou seja, vc recebeu os dados da tela e deve criar as classes de negócio, ai vai de cada um!

Vc pode instanciar cada objeto sem relacionar eles entre si, mas acho isso chato!!! Nada impede de um dao conhecer outro dao também. Assim você passa o dvd para o dao dvd e ele se encarrega que setar criar as musicas e o autor!!!

Se por acaso é muito trabalhoso ficar pegando dado por dado e ficar setando todos os objetos de negócio, e se isso for gerar muita duplicação de código, é só quebrar essas atividades em alguns métodos, assim não vai ser preciso muita munheca também!!!

Eu pelo menos procuro sempre trabalhar o máximo possível na minha estrutura de negócios… e uso o DAO só em última instância… ou seja, persistir… só!!!

Só mais uma coisa! o fato de usar classeNegocio e classeNegocioDAO é simplesmente é porque adotei que assim que faço a modelagem, eu costumo fazer tudo na classe de negócio mesmo. Então o dvd teria os métodos create, delete e etc… Mas na hora de implmentar, ao invés de eu deixá-los na classe de negócio é só eu passar para o seu DAO correpondente, que seria o DvdDAO…

Agora se ninguém curtiu DAO, o jeito é usar IoC, igual o fabgp me recomendou uma vez em um outro fórum. Naquela época nem sabia o que era isso, agora que já dei uma olhada, achei muito bom e dá para fazer com que a classe de negócio seja responsável por persistir seus próprios dados… mas… não perguntem para mim como!!!

Espero ter ajudado!
Abraços!

Thiago Senna:

Bom… seria sim na munheca!!!

Abraços!

Bah ehehe retrabalho Hibernate neles Thiago, mata esses DAO ae ehehehe

PS: criando confusão…

Pessoal… me tirem uma dúvida!

Afinal, como vocês estão usando o DAO?? VocÊs estão usando da mesma forma que eu ou usam diferente??

Abraços!

Eu costumo utilizar desta forma, só não tão expecialista, mas mais genérico.

No exemplo que voce mostrou, por exemplo, eu faria um DAO só para persistir o DVD, e dentro deste persistiria também as músicas e autores.

Mas é basicamente assim mesmo que uso.

Thiago Senna:

Pessoal… me tirem uma dúvida!

Afinal, como vocês estão usando o DAO?? VocÊs estão usando da mesma forma que eu ou usam diferente??

Abraços!

Bom aqui tneho dois modos, uma é com os DAOs, tenho uma interface DAO, e um DAO com métodos especificos para cada BD. EX:

AlunoDAO - interface
AlunoOracleDAO - classe com métodos para oracle que implimenta AlunoDAO
AlunoSqlServerDAO - classe com métodos para oracle que implimenta AlunoDAO

Os negócios sempre acessam a interface, quem cuida de me trazer o DAO referente é uma Factory, desse modo posso trazer método que quiser referente ao banco que quiser, sem ter que mecher nos meus negócios e tal. É por meio de Facade sim Thiago ehehe

A seugnda opção, é usarmos Hibernate, a qual acho mais interessante, por ser mais flexível, e precisar somente passar um único objeto com seus relaiconamentos e ele cuidar do resto.

Na primeira já não existe esta flexibilidade, se precisarmos guardar algum relacionamento, segue-se a velha prática de fazer dois insert ( ecaaa) e dependo do programador(as vezes eu mesmo por preguiça ) gera coisa duplicada, mesmo sql em 3, 4 métodos por causa desses relacionamentos, só merda ehehe

É por ae.

humm …entendi!!!

Então… o que o meu tem de diferente do seu é simplesmente que, ao invés de eu fazer a persitência dentro do próprio dvd, eu delego a tarefa de delegar a musica para o musica dao…

Então, eu chamo o dvdDAO, que persiste o dvd. O dvdDAO possui uma instância de musicaDAO, que se responsabiliza por persistir as músicas!!

Bom…
Valeu mesmo!
Abraços!

Entendi Skill…
Gostei da sua colocação quando ao Façade… hehehe!!!

Realmente… neste caso o façade é bém vindo… mas por que você não optou por usar uma fábrica abstrata de DAO???

Não seria melhor???

Abraços!

Thiago Senna:

Entendi Skill…
Gostei da sua colocação quando ao Façade… hehehe!!!

Realmente… neste caso o façade é bém vindo… mas por que você não optou por usar uma fábrica abstrata de DAO???

Não seria melhor???

Abraços!

Acho que você não entendue ou eu falei pouco ehehe

Eu disse que eu tnho um Factory, que seria isso que você está dizendo, ela me traz o dao que eu pedir

Assim:

Controller -> negócio -> Facade -> Factory de DAOs -> DAO específico

é quase isso ae eheh, tem mais uns Helpers, Entytes ai no meio hehe

Thiago Senna:

Pessoal… me tirem uma dúvida!

Afinal, como vocês estão usando o DAO?? VocÊs estão usando da mesma forma que eu ou usam diferente??

Abraços!

Sendo objetivo. Diferente.

Mas essa delegacao deveria ficar por conta do proprio DAO e nao tu ficar fazendo tudo na munheca.
Do jeito que eu mostrei la em cima e tu confirmou, nao existe uso de relacionamento de objetos direito, quem tem que montar os relacionamentos é a camanda de negocio e isso é muito ruim é como trabalhar com Hibernate sem usar os relacionamentos, pra quem ja fez isso (assim como eu) ja deve ter passado muitas noites sem dormir.

A meu ver nao usar relacionamento de objetos, tu acaba criando um dominio muito pobre e isso pode influenciar até na camada de visao em relatorios, telas master-detail, etc.

]['s

Ter que usar expressoes como “eu delego a tarefa de delegar a Musica para o MusicaDAO” por si so ja indica que algo esta errado, nao?

Eu imagino um cara pegando o sistema pra dar manutencao depois de 1 ou 2 anos.
O cara ira tecer elogios ao Thiago nao muito bons de falar aqui no Forum :mrgreen:

aff… pronto… lá vem malhação!!!

Mas como assim o domínio fica pobre???
Por acaso vocês criam um dao que se chama dvdDAO e ai dentro do método ele sai persistindo musica, dvd e artista… mas tudo no mesmo corpo do método??? O que eu faço é que dentro do método dvdDao.create() eu chamo musicaDao.create()… simplesmente para reaproveitar código!!

Isso não é melhor??? Afinal, onde estou ferindo os relacionamentos da classe de negócio??

Thiago Senna:

aff… pronto… lá vem malhação!!!

Mas como assim o domínio fica pobre???
Por acaso vocês criam um dao que se chama dvdDAO e ai dentro do método ele sai persistindo musica, dvd e artista… mas tudo no mesmo corpo do método??? O que eu faço é que dentro do método dvdDao.create() eu chamo musicaDao.create()… simplesmente para reaproveitar código!!

Isso não é melhor??? Afinal, onde estou ferindo os relacionamentos da classe de negócio??

Que tal pegar tudo esses DAO largar na lixeira e comecar a usar Hibernate? :mrgreen:

Sinceramente eu nao gosto desse negocio ai. Imagina a seguinte situacao, alem de DVD minha loja tem CD, Vinil. Ai tu vai criar uns DAO’s para eles.

CDDao
VinilDAO

Como tu faz? Fica espalhando instancia de MusicaDao dentro deles??

]['s

é seria isso sim… espalhamento de musicaDAO…

Bom… como você já citou uma vez fabgp, hibernate na cabeça e IoC na veia!!!

Eu só usando os daos por que sou obrigado a usá-los… por enquanto né…
Mas já comecei a estudar e spring e hibernate para sair desse mundo escuro dos daos!!!

Valeu pelo apoio… mas só vamos tomar cuidado para não dar um nó na cabeça da galera que tá começando… tipo igual esse nó que vcs colcaram na minha cabeça agora!!!

Abraços!!! :lol: :lol:

Thiago Senna:

tipo igual esse nó que vcs colcaram na minha cabeça agora!!!

Abraços!!! :lol: :lol:

Nós são bons, principalmente quando desatam

Imagine se não houvesse estes nós, até hoje eu estaria fazendo tudo na mesma classe hehehe

Nao esquenta Thiago, eu tb uso coisas que nao gosto, mas o cara faz o que é preciso. :mrgreen:

]['s

Olá

Não há nada errado em usar DAOs. Eles continuam sendo ótimos como uma camada de abstração para separar a lógica de persistencia da lógica de negócios. DAO foi definido no livro Core J2EE Design Patterns como um pattern para abstrair e encapsular todos os acessos as fontes de dados sendo estas bases de dados, repositórios LDAP ou qualquer outra que se imaginar. Na realidade DAO é apenas um caso especial do pattern Strategy do GoF.

É importante saber que as vezes a separação é dificil de se conseguir e até mesmo impossível sem comprometer a performance ou sem forçar cada implementação a usar um mapeamento O/R ou um VO. Lembro que DAO pode usar um mapeamento O/R, mas DAO não é o mesmo que mapeamento O/R.

O importante é tentar que a interface DAO permita uma implementação eficiente sem ditar a estratégia de persistência. Falei interface porque se deve criar os DAOs como interfaces ao invés de classes.

Thiago, espero que você continue usando DAOs e cada vez melhor. Aproveite tudo o que foi falado aqui para organizar suas idéias e aprender. Não pense que o Fábio ou o CV nasceram sabendo tudo isto, eles devem ter lido muito. Este é o caminho.

[]s
Luca

Galera eu comecei a discursão e aprendi um monte de coisas, comecei a usar esse DAO, mas voltando a minha primeira pergunta…

Comecei a programar colocando as objetos de classe ao invés de de só o campo id.

Antes

class CD{

int id;

String desc;

int idArtista;

}

class Artista{

int id;

String desc;

}

Depois:

class CD{

int id;

String desc;

Artista a;

}

class Artista{

int id;

String desc;

}

Meu dilema agora é:

class Main{

CD cd = new CD();

Artista a = new Artista(); // Meio estranho não é? eu só presciso do id!

a.setId(1)  ;

a.setNome(“EU”);

cd.setA(a) ;

}

Tou achando meio estranho ter que instanciar um objeto da classe Artista, popular e depois salvar no cd.

Pois digamos que eu esteja no servlet CD no método processaSalvar, eu só presciso do id do artista pra cadastrar o cd, mesmo assim tenho que le o request, instancia um objeto artista, setar a propriedade id depois setar no cd, Não é mais trabalhoso se eu só tivesse na classe cd o id do Artista?

Deu pra entender? (hehehehe)

Por enquanto não estou vendo vantagens.

Elias, quer uma dica pra resolver isso?

Você deveria estar usando 1 framework MVC que te popula VOs baseado no request, correto? Se ele for flexivel o suficiente, altere para aceitar popular a propriedade artista instanciando um objeto e passando a PK.

Não uso framework, apenas servlets.

Elias, isso não é estranho!!!

É mais trabalhoso… mas você não pode fazer suas classes como se fossem banco de dados… aqueles diagramas DER!!

se vocÊ precisa do ID, é só vc escrever o seguinte

cd.getArtista().getID()… pronto!!!

Abraços!

O pessoal tem cada fetiche estranho :mrgreen:

A questão do artista em questao (!!!) é:

Códigos são legais par auma tabela referenciar a outra, para um objeto referenciar o outro, use uma referência.

Se seu Artista possui mais que um código como atributo, faz mais sentido você ter algo que se relaciona com o Artista (aponta pra ele) do que algo que sabe o código do artista e trabalha com ele (um dado privado).

Em outras palavras é melhor você ter um :

class CD { String nome; String preco; Artista artista; }

Do que:

class CD{ String nome; String preco; Long idArtista;

É isso que você quis dizer Phillip?!?

Exato

Exato, Rafael… quanto menos partes do sistema sequer souberem que o Artista tem um ‘id’, esse treco artificial que vc colocou na classe por causa da persistencia

E mais um conselho, não faça:

if(pearlJam.getCodigo()==creed.getCodigo()){
japoneix();
}

Pelo amor de Zahl, faça:

if(creed.equals(pearlJam){
 japoneix();
}

Não espalhe os dados das suas entidades musicais pelo sistema sem necessidade

Phillip,
Mas para fazer isso:

if(creed.equals(pearlJam){ japoneix(); }
Eu teria de implementar um método equals() em todas as minhas classes. Não seria gerar um trabalho desnecessário?

Se você quer criar boas abstrações, não.

Primeiro, você tem certeza que vai querer espalhar seus ifs por um milhão de lugares diferentes no código, podendo ao invés disso chamar um método?

Além do que, como o Carlos mencionou, o ID é algo artificial, geralmente precisamos criar dados assim para coisas como persistência ou comunicação entre sistemas, na maioria isso interessa a apenas uma ou duas classes numa única camada.

Se você amarrar todas as classes clientes da sua ao conceito de ID (pra começar já vai estar expondo um dado a mais!), você vai fazer com que todas dependam do atributo artificial que foi feito só para uma “gambiarra” qualquer.

Além do que, o papel de definir se um objeto é igual ao outro é relativo. De repente, o ID não é tão importante, eu não poderia ter duas bandas chamadas “Creed”, então meu equals deveria comparar os nomes também. Se eu fizer um && em todos os meus ifs espalhados por aí que comparam os códigos… putz, você vai aumentar o acoplamento enormemente por todo lugar.

Faça os clientes dependerem o quanto menos possível dos atributos das classes que disponibilizam um serviço, evite código repetido.

É claro que num sistema muito simples implementar equals pode ser um overhead, cabe a quem está programando analisar as opções, mas se você quer manter um acoplamento baixo, não dependa dos atrbiutos dos objetos

Olá

Além do que o Phillip falou, saiba que fazer override de equals as vezes é ótimo, mas pode dar zebra. Lembre-se do capítulo 3 do livro Effective Java do Joshua Bloch que TODOS os programadores Java precisam ler ao menos uma vez:

Chapter 3, “Methods Common to All Objects”
:arrow: item 7: Obedeça ao contrato geral.
Regras básicas:

• Não faça este override se:

1. Cada instância da classe é única (exemplo: Thread)
2. equals herdado de Object ou de uma superclasse é adequado
3. A classe é privada (ou só visível dentro do pacote) e o equals nunca será chamado
   Caso faça o override:
4. Use o operador == para verificar se o argumento é uma referência a este objeto
5. Use o operador instanceof para verificar se o tipo está correto
6. Coloque cast no argumento para o tipo correto
7. Para cada campo “significante” da classe verifique se o tipo do campo é o mesmo do argumento
8. Depois de pronto o método equals pergunte a si mesmo se ele é simétrico, transitivo e consistente.

:arrow: item 8: Sempre faça override de hashCode ao fazer override de equals

Mas por favor, sempre faça override do toString

[]s
Luca