Dúvida sobre Modelagens de Beans e Padrões

Caros amigos,

Apesar de ser uma pergunta simples mas gostaria de saber o porquê que é melhor colocarmos um bean com atributo de um outro,por exemplo,

public class CD{
int id ;
String nome;
Artista at;
}

public class Artista{
int id;
String nome;
CD [] cd;
}

Ao invés de colocar apenas um id, como artistaID na classe CD, já que eu trabalho com banco de dados relacional? Caso queira recuperar os dados do artista, consulto no banco pelo id e o populo. Este caso é simples, imagine um bean cliente com enderecos, contatos, pedidos, vendas e etc, seria varios atributos e o bean não ficaria enorme desnescessáriamente?

Sei que ha alguma coisa errada com meu pensamento, gostaria da opinião de voces.

Um abraço a todos!
Obrigado.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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!!!

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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!

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

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

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