Dúvida sobre Modelagens de Beans e Padrões

Programação Arquitetura
#1

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.

#2

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!

#3

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…

#4

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

#5

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!

#6

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.

#7

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?

#8

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

#9

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…

#10

É 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?

#11

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

#12

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!

#13

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 :slight_smile:

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?

#14

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!

#15

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

#16

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

#17

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

#18

Boa pergunta… E muito crucial para mim…

#19

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!

#20

[quote=Thiago Senna]Bom… seria sim na munheca!!!

Abraços![/quote]

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

PS: criando confusão…