Qual é a melhor pratica para relacionar notas fiscais ao Cliente?
ou
1 curtida
Antes de tudo você precisa de ter os requisitos de quem vai precisar desse sistema. Fora isso, dá uma estudada aqui: http://www.macoratti.net/cbmd1.htm. Inclusive lá tem um caso parecido de como poderia ficar o seu:
1 curtida
1 Cliente pode ter várias notas fiscais
1 Nota é de apenas um determinado Cliente
Na minha visão e falando pela simples pergunta, claro que a primeira porque o relacionamento é (1:N) onde 1 é o Cliente e N são as notas fiscais.
Pelo que entendi desse exemplo, não seria nenhuma das opções que dei e sim:
Talvez a Nota Fiscal ter informação do cliente seja um acoplamento menor do que o Cliente ter uma lista de Notas Fiscais…
isso é um parece ser detalhe de implementação do ORM: nada impede de vc carregar uma lista de notas fiscais Lazy via Hibernate e quando precisar vc apenas percorre a lista.
porém isso talvez faça mais sentido se vc adicionar ao modelo de dados um RepositorioDeNotasFiscais que recebe um cliente e traz tudo o que for relacionado a ele.
Não entendi voce achar ser um problema o Cliente ter uma lista de NF, se esta é a realidade.
O problema é que sempre que eu precisar instanciar um cliente, obrigatoriamente, precisarei carregar uma lista de NFs. Mesmo se for em um local do sistema que não precise saber as notas fiscais…
Entendi o Lazy… realmente resolveria o problema de não ter q carregar NFs sempre que instanciar um Cliente… não entendi a parte do Repositorio… não que não tenha entendido… não sei como fazer…
Não vai ser obrigado, isso é detalhe de implementação como o @peczenyj falou.
Com SQL você tem a liberdade de atender as funcionalidades do jeito que for necessário. Escrever SQL diretamente é mais prático, já com ORM você vai ter que saber usar os recursos disponíveis nele, onde no final das contas também vai ter que entender os SQLs gerados pela ferramenta. Se for aplicação web/HTTP, ler efetivamente propriedades lazy não tem eficiência, vai cair no problema de n+1 querys quando for ler as NFs. Você vai ter que somente deixar mapeado como lazy e aplicar fetch join usando Criteria/Hql/Jpql ou sei lá mais o que tenham inventado.
Repositorio é um pattern bem comum em Domain Driven Development. ele substitui o DAO com mais semantica.
Pense assim: suas notas fiscais vivem em ‘memoria’. uma hora vc tem que salvar elas pq se acabar a luz PUF elas somem. vc usa o banco de dados para isso.
O Repositorio é uma classe que sabe recuperar / salvar/ etc. É uma questão de semantica.
Vc quer saber as notas fiscais associados ao usuario x? pergunta pra essa classe. Ela sabe resolver as coisas.
Para CRUD simples, realmente parece ser o mesmo que um DAO. Porem o DAO vive na sua camada de infra-estrutura. Se vc resolver trocar ao inves de mysql vc quer salvar em arquivo ( sei la pq ) ou resolveu usar um banco de dados nosql, vc altera no DAO. O Repositorio continua sendo a sua interface com o seu modelo de dados.
Pra saber mais, da uma lida sobre DDD quando vc achar apropriado
Resumindo…nao faria muita diferença o Cliente ter uma lista de NFs ou não… Sendo que de qualquer forma…na NF precisa ter a referencia do Cliente…se não seria apenas uma NF solta…
Entendido em partes… vou com toda certeza pesquisar sobre DDD! 
Sim, mas além dos dados do cliente diretamente na Nota conforme época emitida, costuma ser necessário ter o cadastro do cliente atualizado independente de NFs. Na implementação você terá a liberdade de consultar qualquer dado sem essas “obrigações” a qual se referiu.