Caros amigos, como fica essa questão do modelo anêmico quando usamos ORM, pois o próprio Framework nos força a implementar classes que funcionem apenas para representar tabelas, e por habito separamos nosso DAO's em outras classes, caindo meio que num modelo de programação procedural como no post seguinte http://blog.caelum.com.br/o-que-e-modelo-anemico-e-por-que-fugir-dele/. Gostaria de um exemplo concreto (de experiência profissional) por parte dos instrutores como usar ORM sem cair no modelo anêmico,e por favor não usem esses exemplos com uma classe conta ou pessoa. Grato.
Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas
respostas
Modelo anêmico
Diego, sempre tive essa curiosidade também de encontrar um modelo real da não-utilização do modelo anêmico.
O único exemplo que encontrei na net foi no github da caelum mas mesmo assim ele é mto básico (não sei se você já tinha visto).
https://github.com/caelum/pm87-agiletickets
Se encontrar algo mais concreto não deixe de compartilhar x)
Abraços
Ok, baixei o arquivo, obrigado. Vou dar uma analisada no código, essa é uma duvida que sempre pairou na minha cabeça quem sabe alguém da Caelum que possui experiencia prática nos de uma luz!
solução!
Oi Diego, a discussão já está aberta a um tempo, mas gostaria de acrescentar. Nem sempre é possível deixar o modelo não anêmico. Isso se dá muito pela estrutura da linguagem Java.
Pense o seguinte, se você quer a Nota Fiscal de uma determinada compra, como você faria para obter a nota?
compra.obterNotaFiscal() ou notaFiscalDao.buscaPorCompra(numeroPedido)?
O primeiro modelo seria muito mais natural correto? Porém se imaginarmos o que será necessário para a entidade compra obter a nota fiscal, iremos lembrar que é preciso ir no banco de dados, e para ir no banco, é preciso conexão, transação, datasource, etc.. Imagine colocar tudo isso dentro da classe Compra? Estaríamos fazendo uma salada só na classe e ao tentar torná-la não anêmica estaríamos quebrando a regra de responsabilidade. A Compra teria que ter conexão ou no caso de JPA Entity Manager. O que não tem nada haver com a Compra em si.
public class Compra {
@PersistentContext
private EntityManager manager;
private NotaFiscal notaFiscal;
// demais atributos
}Por essa razão, nossas entidades são praticamente modelos anêmicos, mas quando possível e quando temos lógicas que não dependem do banco, podemos utilizar a classe para tal, como no exemplo que o Rodolfo colocou.
Por que falei que o Java quase nos obriga a isso? Porque em Rails/Javascript e outras linguagens dinâmicas, podemos criar classes que possuem o modelo que ela representa e em outra classe, adicionar as funcionalidades desejadas aquela entidade. Não fazemos tudo na classe Compra direto, por exemplo, essa classe teria apenas o modelo e ficaria mais enxuta, mas ainda assim seria possível fazer compra.obterNotaFiscal() e esse método ir ao banco sem "sujar" a classe com objetos de persistencia.
No mais, acabamos deixando nosso modelo um pouco anêmico, mas separamos as responsabilidades nos Services e DAOs do sistema.