Solución:
La anotación se utiliza para evitar la creación de servidores proxy de repositorio para interfaces que realmente coinciden con los criterios de una interfaz de repositorio, pero que no pretenden serlo. Solo es necesario una vez que comienza a ampliar todos los repositorios con funcionalidad. Dejame darte un ejemplo:
Suponga que le gustaría agregar un método foo () a todos sus repositorios. Comenzaría agregando una interfaz de repositorio como esta
public interface com.foobar.MyBaseInterface<…,…> extends CrudRepository<…,…> {
void foo();
}
También agregaría la clase de implementación correspondiente, la fábrica, etc. Sus interfaces de repositorio concretas ahora extenderían esa interfaz intermedia:
public interface com.foobar.CustomerRepository extends MyBaseInterface<Customer, Long> {
}
Ahora suponga que arranca, digamos Spring Data JPA, de la siguiente manera:
<jpa:repositories base-package="com.foobar" />
Tu usas com.foobar porque tú tienes CustomerRepository en el mismo paquete. La infraestructura de Spring Data ahora no tiene forma de decir que el MyBaseRepository no es una interfaz de repositorio concreta, sino que actúa como repositorio intermedio para exponer el método adicional. Por lo tanto, intentaría crear una instancia de proxy de repositorio para él y fallaría. Ahora puedes usar @NoRepositoryBean para anotar esta interfaz intermedia para decirle esencialmente a Spring Data: no cree un bean proxy de repositorio para esta interfaz.
Ese escenario es también la razón por la que CrudRepository y PagingAndSortingRepository lleve también esta anotación. Si el escaneo de paquetes los detecta por accidente (porque lo ha configurado accidentalmente de esta manera), el bootstrap fallaría.
En pocas palabras: use la anotación para evitar que las interfaces del repositorio sean elegidas como candidatas para terminar eventualmente como instancias de beans de repositorio.