No texto anterior sobre o assunto falei um pouco sobre a implementação do pattern Repository mostrando um pouco a minha implementação do AbstractRespository, que fornece uma implementação default para as operações genéricas de CRUD.

A idéia principal do AbstractRepository é fornecer algumas operações genéricas, principalmente de CRUD, afim de evitar muitos dos métodos dos Repositorys que simplesmente delegam para o DAO o trabalho. Mas temos que tomar alguns cuidados com aberrações descritas neste texto e nos comentários do texto anterior.

Da forma que foi implementado, o AbstractRepository esta muito parecido com um DAO (mas não é, como vamos ver adiante). Humm ... faz sentido, a idéia base que eu usei foi de um AbstractDAO mesmo. Acho que posso evoluir a idéia.

Para começar, vamos tentar entender oque é um repositório.

Na Wikipedia um repositório é mais ou menos isso:  "Um lugar onde dados são armazenados e mantidos".

Já a definição de Repository descrita no P of EAA, dentre muitas palavras diz : "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects"

Veja que um repositório não deve se precupar com a forma que os objetos são persistidos. Estas preocupações mundanas devem ser de responsabidilade de um DAO, que faz o mapeamento dos objetos para um meio de persistência (Lists em memórias, base de dados, arquivos XML, pergaminhos, etc etc etc). 

Puxa, mas até hoje abstraimos e abstraimos os nossos DAO para que a suas interfaces fiquem longe da implementação de como se vai persistir os objetos e vem agora dizer que isso ainda não é o suficiente ?

Basicamente é isso mesmo. O DAO ainda expoões coisas que não interessa às classe de domínio. E pode ser que falte algumas coisas.

Precisamos criar mais uma camada nesta nossa lazanha, o Repository, que é uma classe para ser acessada diretamente pelas classes de domínio. Nota mental: Camadas em execesso deixam a lasanha pesada e de difícil digestão.

Mas vamos refletir um pouco mais. Será que não podemos encarar o JPA como um DAO já prontinho e abstraido o suficiente para nós? Para que abstrair ainda mais a nossa persistência de dados?
Nos livramos do peso da implementação do DAO quando usamos o JPA. Ufa! :-) 

Aqui vale só mais um paragráfo. Se olharmos com alguma atenção, JPA por si só representa um Repository. Porém acho que é seria muito "cru" para ser acessado diretamente pelas clesses de domínio. E principalmente seria trabalhoso, ou impossível, reutilizar as consultas. Mas isso é assunto para ser discutido a parte.Em apenas um parágrafo não dá.

Bom, beleza. Usando o JPA como DAO e abstraindo este acesso à persistência e expondo uma interface "limpinha" para as classes de domínio a nossa AbstractRepository volta ao status de Repository?

Ainda não sabiá!

Da forma que a AbstractRepository foi implementada ainda temos os problemas expostos pelo Phillips nos comentários, e endossados por mim por experiência própria, de que as especializações dos Repositorys corregam as operações genéricas de CRUD, mesmo quando não fazem o menor sentido. Por exemplo  um UnidadesDaFederaçãoRepository teria as operações de delete e update. Isso faz sentido? Na maioria dos casos não. 

O ideal seria que o  UnidadesDaFederaçãoRepository tivesse apenas as operações  que fazem sentido ao negócio, de list e find por exemplo.

Como fazer isso de forma simples, sem criar muitas classes para isso ?
Podemos criar um interface UnidadesDaFederaçãoRepository apenas com os métodos necessários ao dominio. Desta forma temos a classe concreta UnidadesDaFederaçãoRepositoryImpl que estende da AbstractRepository e implementa a  interface UnidadesDaFederaçãoRepository.

A classe RepositoryFactory, usada para  obter a implementação de um determinado repositório constrói a UnidadesDaFederaçãoRepositoryImpl mas retorna apenas a interface UnidadesDaFederaçãoRepository.

Pronto!

Fico devendo a implementação de tudo isso. "Show me the code", diria Linus Torvalds. :-) 

Respostas[1]

Publicado por Alexandro D. Almeida em 28 de Novembro de 2007 8h26min32s BRST #