Fabio Kung:
sergiotaborda:
Cara, uma coisa é o conceito e a utilidade do repositorio. Outra coisa é ORM.
Misturar os dois dá merda.
O problema é que @manyToOne resolve em certas circusntâncias. Como já foi dito : se usar hibernate é tudo uma maravilha, mas se usar JDBC é um pesadelo. Mas Hibernate e JDBC são tecnologias de persistencia.
Ahn?
Problema: quero os alunos dada uma turma.
ORM decente: List<Aluno> alunos = turma.getAlunos();
JDBC Puro: List<Aluno> alunos = repositorio.getAlunosDa(turma);
Sem ter um repositório dentro da entidade, não há como fazer a primeira alternativa usando jdbc puro. Portanto a escolha de usar um orm decente impacta sim em como você vai usar os seus repositórios. Não dá para nivelar sempre por baixo e fazer tudo como se você estivesse usando só JDBC puro. Para que ignorar o fato de que existe um ORM que permite níveis de abstração maiores?
E depois vc se interroga porque fico explicando a diferença entre repositorio e DAO.
Um mecanismo ORM é um tipo especifico de DAO. Então não interessa que mecanismo eu estou usando para a persistencia porque o DAO me isola disso. Esse é o papel do DAO: isolar a API de persistencia. Seja JDBC, seja Hibernate seja o que for.
Eu posso fazer List<Aluno> alunos = turma.getAlunos() em qualquer esquema de persistencia. Eu não apenas posso, como DEVO. Porquê? Pela simples razão que esse código representa uma relação direta entre turma e aluno. É uma relação de dominio. É uam relação do modelo! Não devo simplesmente usar o segundo codigo. Pelo menos não se estiver usando DDD.
(Tlv seja uma falha minha, mas se a pessoa fala em repositorio eu assumo que ela está usando DDD e portanto o objetivo final é ter classes de dominio corretas. Agora, se vc está falando fora de DDD ai vc faz o que quiser e como quiser. Só que se vc falar de repositorio fora de DDD não faz sentido absolutamente nenhum. Já que se não um modelo de dominio bem definido, vale tudo.)
Depois vc está esquecendo que as classes do dominio/modelo são desacopladas da intraestrutura. Logo, aquele codigo vai funcionar em qualquer ocasião porque o Repositorio vai se encarregar que assim seja. Que truques o repositorio usa para fazer isso não interessa. O que interessa é que vc SEMPRE vai poder usar o modelo na sua forma pura sem recurrer a truques ou a métodos “globais” como repositorio.getAlunosDa(turma).
Usar este tipo de codigo é fazer modelos orientados a banco de dados e não modelos OO.
de um lado da moeda:
O objeto turma mantém as suas relações de MODELO. A turma tem alunos e está assignada a professores.
Tem um horario, etc… No modelo, Turma tem tantas relaçoes como a turma real tem no mundo real.
O objeto turma é consciente que tem uma coleção de alunos associada a ele e ele permite acesso a ela com getAlunos(). Isto é modelagem. Isto é orientação a dominio.
do outro lado da moeda:
O repositorio da turma tem que garantir que o objeto turma seja incluido na lista de turmas existentes e que o seu estado seja conservado. Porque quando o dominio puxar um “getTodasTurmas()” essa turma tem que estar lá. E tem que estar lá com todo o seu grafo de objetos relacionados. Alunos, Professores, etc…
O ponto é que o repositorio da turma sabe conservar turmas. Apenas turmas. Portanto ele tem que delegar a outros repositorios a conservação dos outros tipos. O ponto é que ele sabe como uma turma é formada. O repositorio é um objeto do dominio. Ele tem conhecimento das entidades e das suas relações e ele vigia que essas relações seja mantidas de forma coerente. Então, o repositorio sabe que turma tem vários alunos e professores e ele sabe que tem que delegar a conservação desses tipos aos repositorios apropriados.
Isto ainda é orientação ao dominio, mas agora não do ponto de vista da turma individual, mas do ponto de vista do cara que tem que manter todas as turmas. O objeto turma está preocupado em manter um coleção dos seus alunos. Os repositorios estão preocupados em manter a coleção e todas as turmas e todos os alunos.
O primeiro caso vc resolve facil com uma coleção privada e desacoplada : um arraylist da vida.
O segundo caso vc não resolver apenas um coleções porque vc precisa de alguma logica que destinga de entre todos os alunos do sistema, quais pertencem a qual turma.
Na “cabeça” de um repositorio não existem bancos de dados. Existem coleções de objetos e relações entre eles que têm que ser mantidas. Mas elas são mantidas com logica programada no repositorio e não com mecanismos externos.
Por isso que ue falei que é necessário entender a diferença entre repositorio e DAO e onde fica a fronteira.
As informações de um repositorio não têm obrigação de ser persistentes. A persistencia é um mecanismo artificial que permite que o programa deixe de executar e depois volte a executar como o estado inalterado. Só isso. Não é a razão de vida de um sistema. Muito menos de um repositorio.
Para descobrir os alunos com nota maior que 8 não é necessário um repositório inteligente. Apenas um serviço que faça esse processo. E funciona ± assim:
Service {
public List<Aluno> alunosNotaMaior(Disciplina d , int nota){
RepositorioAlunos rep= ...
List<Aluno> alunos = new LinkedList(rep.getAll());
for ( Iterator it = alunos .iterator(); it.hasNext();){
Aluno aluno = it.next();
if ( ! (aluno.getNota ( d ) > nota )){
it.remove();
}
}
return alunos;
}
}
Não. A escolha de ter um repositorio se deve a vc querer um modelo simples, rico e independente de estrutura.
Vc tem um repositorio se vc está querendo esses objetivos.
Se além disso vc quer persistencia, vc tem um DAO ( que pode ser JDBC puro sim)
Se além disso vc quer ter um mecanismo padrão para o DAO com JDBC vc usa ORM.
Entenda que ORM não é o objetivo é apenas uma ferramenta.
se o o seu DAO é JCache ou JGroups não ha ORM. Se o seu dao é XML não ha ORM.
Se a escolha do ORM inpacta o seu modelo então para que serve o DAO ? Afinal que isolamento é esse ? Isolamento poroso ? Se o ORM impacta o modelo o seu sistema é fortemente acoplado. Pior ainda, só funciona dessa maneira. Então para quê complicar com DAO e repositorios ? Arranque isso fora , deixe o ORM puro e pronto. Vai ganhar um monte em simplicidade e poupar um monte de camadas inuteis no seu sistema.
Os padrões têm objetivos. Se vc não tem esses objetivos porque usar os padrões ? Moda ?
Eu já falei isto tantas vezes mas parece que não me consigo fazer entender. 
. Existe um problema reccorente que é o fato dos objetos não serem auto persistidos. A melhor forma que se encontrou pra resolver isso foi essa. Tinhamos o DAO, que na verdade é um DataMapper misturado com Repository IMO. Achou-se interessante criar esse conceito de Repository para fazer parte do domínio.
