Qual é a diferença entre CrudRepository e JpaRepository interfaces Primavera de dados JPA ?
Quando vejo os exemplos na web, vejo-os lá usados de forma intercambiável.
Qual a diferença entre eles?
Por que você gostaria de usar um sobre o outro?
Respostas:
JpaRepositoryestende PagingAndSortingRepositoryque por sua vez se estende CrudRepository.
Suas principais funções são:
CrudRepository fornece principalmente funções CRUD.PagingAndSortingRepository fornece métodos para fazer paginação e classificação de registros.JpaRepository fornece alguns métodos relacionados à JPA, como liberar o contexto de persistência e excluir registros em um lote.Por causa da herança mencionada acima, JpaRepositoryterá todas as funções de CrudRepositorye PagingAndSortingRepository. Portanto, se você não precisa que o repositório tenha as funções fornecidas por JpaRepositorye PagingAndSortingRepository, use CrudRepository.
A resposta de Ken está basicamente certa, mas eu gostaria de comentar "por que você quer usar um sobre o outro?" parte da sua pergunta.
A interface base que você escolhe para o seu repositório tem dois propósitos principais. Primeiro, você permite que a infraestrutura do repositório do Spring Data encontre sua interface e inicie a criação do proxy para injetar instâncias da interface nos clientes. O segundo objetivo é atrair a funcionalidade necessária para a interface sem precisar declarar métodos extras.
A biblioteca principal do Spring Data é fornecida com duas interfaces básicas que expõem um conjunto dedicado de funcionalidades:
CrudRepository - métodos CRUDPagingAndSortingRepository- métodos para paginação e classificação (estende CrudRepository)Os módulos de armazenamento individuais (por exemplo, para JPA ou MongoDB) expõem extensões específicas da loja dessas interfaces básicas para permitir o acesso a funcionalidades específicas da loja, como descarga ou lote dedicado, que levam em consideração alguns detalhes da loja. Um exemplo para isso é deleteInBatch(…)de JpaRepositoryque é diferente de delete(…), uma vez que utiliza uma consulta para excluir as entidades dadas, que é de maior performance, mas vem com o efeito colateral de não desencadeando as cascatas definida-APP (como os define especificações TI).
Geralmente, recomendamos não usar essas interfaces básicas, pois elas expõem a tecnologia de persistência subjacente aos clientes e, assim, aumentam o acoplamento entre eles e o repositório. Além disso, você se afasta um pouco da definição original de um repositório que é basicamente "uma coleção de entidades". Então, se você puder, fique com PagingAndSortingRepository.
A desvantagem de depender diretamente de uma das interfaces de base fornecidas é dupla. Ambos podem ser considerados teóricos, mas acho que são importantes:
Pageou Pageableno seu código de qualquer maneira. O Spring Data não é diferente de nenhuma outra biblioteca de uso geral como o commons-lang ou o Goiaba. Contanto que forneça benefícios razoáveis, tudo bem.CrudRepository, por exemplo , você expõe um conjunto completo de métodos de persistência de uma só vez. Provavelmente, isso também é bom na maioria das circunstâncias, mas você pode encontrar situações nas quais deseja obter um controle mais refinado sobre os métodos expostos, por exemplo, para criar um ReadOnlyRepositoryque não inclua os métodos save(…)e .delete(…)CrudRepositoryA solução para essas duas desvantagens é criar sua própria interface de repositório base ou até um conjunto delas. Em muitas aplicações, já vi algo assim:
interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }
interface ReadOnlyRepository<T> extends Repository<T, Long> {
// Al finder methods go here
}
A primeira interface do repositório é uma interface básica de uso geral que, na verdade, apenas corrige o ponto 1, mas também vincula o tipo de ID a Longconsistência. A segunda interface geralmente possui todos os find…(…)métodos copiados CrudRepositorye PagingAndSortingRepositorynão expõe os métodos de manipulação. Leia mais sobre essa abordagem na documentação de referência .
A abstração do repositório permite que você escolha o repositório base totalmente orientado por suas necessidades arquitetônicas e funcionais. Use os fornecidos imediatamente, se necessário, crie suas próprias interfaces de base de repositório, se necessário. Fique longe das interfaces específicas do repositório da loja, a menos que seja inevitável.
Resumo:
PagingAndSortingRepository estende CrudRepository
JpaRepository estende PagingAndSortingRepository
A interface CrudRepository fornece métodos para operações CRUD, permitindo criar, ler, atualizar e excluir registros sem precisar definir seus próprios métodos.
O PagingAndSortingRepository fornece métodos adicionais para recuperar entidades usando paginação e classificação.
Finalmente, o JpaRepository adiciona um pouco mais de funcionalidade específica ao JPA.
Todas as respostas fornecem detalhes suficientes para a pergunta. No entanto, deixe-me acrescentar algo mais.
Por que estamos usando essas interfaces:
Qual interface faz o quê:
Quando usar qual interface:
De acordo com http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/
Geralmente, a melhor ideia é usar CrudRepository ou PagingAndSortingRepository, dependendo se você precisa de classificação e paginação ou não.
O JpaRepository deve ser evitado, se possível, porque vincula os repositórios à tecnologia de persistência JPA e, na maioria dos casos, você provavelmente nem usaria os métodos extras fornecidos por ele.
