Je regarde dans Spring Data JPA. Considérez l'exemple ci-dessous où je ferai fonctionner toutes les fonctionnalités crud et finder par défaut et si je veux personnaliser un finder, cela peut également être fait facilement dans l'interface elle-même.

@Transactional(readOnly = true)
public interface AccountRepository extends JpaRepository<Account, Long> {

  @Query("<JPQ statement here>")
  List<Account> findByCustomer(Customer customer);
}

Je voudrais savoir comment puis-je ajouter une méthode personnalisée complète avec son implémentation pour le AccountRepository ci-dessus? Comme c'est une interface, je ne peux pas implémenter la méthode là-bas.

Vous devez créer une interface distincte pour vos méthodes personnalisées:

public interface AccountRepository 
    extends JpaRepository<Account, Long>, AccountRepositoryCustom { ... }

public interface AccountRepositoryCustom {
    public void customMethod();
}

et fournissez une classe d'implémentation pour cette interface:

public class AccountRepositoryImpl implements AccountRepositoryCustom {

    @Autowired
    @Lazy
    AccountRepository accountRepository;  /* Optional - if you need it */

    public void customMethod() { ... }
}

Voir également:

• 4.6 Implémentations personnalisées pour les référentiels de données Spring

• Notez que le schéma de dénomination a changé entre les versions. Voir https://stackoverflow.com/a/52624752/66686 pour plus de détails.

En plus de la réponse d'axtavt , n'oubliez pas que vous pouvez injecter Entity Manager dans votre implémentation personnalisée si vous en avez besoin pour créer vos requêtes:

public class AccountRepositoryImpl implements AccountRepositoryCustom {

    @PersistenceContext
    private EntityManager em;

    public void customMethod() { 
        ...
        em.createQuery(yourCriteria);
        ...
    }
}

La réponse acceptée fonctionne, mais présente trois problèmes:

• Il utilise une fonctionnalité Spring Data non documentée lors de la dénomination de l'implémentation personnalisée en tant que AccountRepositoryImpl. La documentation indique clairement qu'il doit être appeléAccountRepositoryCustomImpl , le nom de l'interface personnalisée plusImpl
• Vous ne pouvez pas utiliser l'injection de constructeur, uniquement @Autowired qui est considérée comme une mauvaise pratique
• Vous avez une dépendance circulaire à l'intérieur de l'implémentation personnalisée (c'est pourquoi vous ne pouvez pas utiliser l'injection de constructeur).

J'ai trouvé un moyen de le rendre parfait, mais non sans utiliser une autre fonctionnalité Spring Data non documentée:

public interface AccountRepository extends AccountRepositoryBasic,
                                           AccountRepositoryCustom 
{ 
}

public interface AccountRepositoryBasic extends JpaRepository<Account, Long>
{
    // standard Spring Data methods, like findByLogin
}

public interface AccountRepositoryCustom 
{
    public void customMethod();
}

public class AccountRepositoryCustomImpl implements AccountRepositoryCustom 
{
    private final AccountRepositoryBasic accountRepositoryBasic;

    // constructor-based injection
    public AccountRepositoryCustomImpl(
        AccountRepositoryBasic accountRepositoryBasic)
    {
        this.accountRepositoryBasic = accountRepositoryBasic;
    }

    public void customMethod() 
    {
        // we can call all basic Spring Data methods using
        // accountRepositoryBasic
    }
}

L'utilisation est limitée, mais pour les méthodes personnalisées simples, vous pouvez utiliser des méthodes d'interface par défaut telles que:

import demo.database.Customer;
import org.springframework.data.repository.CrudRepository;

public interface CustomerService extends CrudRepository<Customer, Long> {


    default void addSomeCustomers() {
        Customer[] customers = {
            new Customer("Józef", "Nowak", "nowakJ@o2.pl", 679856885, "Rzeszów", "Podkarpackie", "35-061", "Zamknięta 12"),
            new Customer("Adrian", "Mularczyk", "adii333@wp.pl", 867569344, "Krosno", "Podkarpackie", "32-442", "Hynka 3/16"),
            new Customer("Kazimierz", "Dejna", "sobieski22@weebly.com", 996435876, "Jarosław", "Podkarpackie", "25-122", "Korotyńskiego 11"),
            new Customer("Celina", "Dykiel", "celina.dykiel39@yahoo.org", 947845734, "Żywiec", "Śląskie", "54-333", "Polna 29")
        };

        for (Customer customer : customers) {
            save(customer);
        }
    }
}

ÉDITER:

Dans ce tutoriel de printemps, il est écrit:

Spring Data JPA vous permet également de définir d'autres méthodes de requête en déclarant simplement leur signature de méthode.

Il est donc même possible de déclarer simplement une méthode comme:

Customer findByHobby(Hobby personHobby);

et si l'objet Hobbyest une propriété du client, Spring définira automatiquement la méthode pour vous.

J'utilise le code suivant pour accéder aux méthodes de recherche générées à partir de mon implémentation personnalisée. Faire passer l'implémentation via la fabrique de haricots évite les problèmes de création de haricots circulaires.

public class MyRepositoryImpl implements MyRepositoryExtensions, BeanFactoryAware {

    private BrandRepository myRepository;

    public MyBean findOne(int first, int second) {
        return myRepository.findOne(new Id(first, second));
    }

    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
        myRepository = beanFactory.getBean(MyRepository.class);
    }
}

Comme spécifié dans la fonctionnalité documentée , le Implsuffixe nous permet d'avoir une solution propre:

• Définir dans l' @Repositoryinterface, par exempleMyEntityRepository , des méthodes Spring Data ou des méthodes personnalisées
• Créez une classe MyEntityRepositoryImpl(le Implsuffixe est la magie) n'importe où (n'a même pas besoin d'être dans le même package) qui implémente uniquement les méthodes personnalisées et annotez cette classe avec @Component** ( @Repository ne sera pas fonctionnera ).
  • Cette classe peut même injecter MyEntityRepositoryvia @Autowiredpour une utilisation dans les méthodes personnalisées.

Exemple:

Classe d'entité:

package myapp.domain.myentity;

@Entity
public class MyEntity {

    @Id
    private Long id;

    @Column
    private String comment;

}

Interface du référentiel:

package myapp.domain.myentity;

@Repository
public interface MyEntityRepository extends JpaRepository<MyEntity, Long> {

    // EXAMPLE SPRING DATA METHOD
    List<MyEntity> findByCommentEndsWith(String x);

    List<MyEntity> doSomeHql(Long id);

    List<MyEntity> useTheRepo(Long id);

}

Bean d'implémentation des méthodes personnalisées:

package myapp.infrastructure.myentity;

@Component // Must be @Component !!
public class MyEntityRepositoryImpl { // must have the repo name + Impl !!

    @PersistenceContext
    private EntityManager entityManager;

    @Autowired
    private MyEntityRepository myEntityRepository;

    @SuppressWarnings("unused")
    public List<MyEntity> doSomeHql(Long id) {
        String hql = "SELECT eFROM MyEntity e WHERE e.id = :id";
        TypedQuery<MyEntity> query = entityManager.createQuery(hql, MyEntity.class);
        query.setParameter("id", id);
        return query.getResultList();
    }

    @SuppressWarnings("unused")
    public List<MyEntity> useTheRepo(Long id) {
        List<MyEntity> es = doSomeHql(id);
        es.addAll(myEntityRepository.findByCommentEndsWith("DO"));
        es.add(myEntityRepository.findById(2L).get());
        return es;
    }

}

Les petits inconvénients que j'ai identifiés sont:

• Les méthodes personnalisées de la Implclasse sont marquées comme inutilisées par le compilateur, donc le@SuppressWarnings("unused") suggestion.
• Vous avez une limite d'une Implclasse. (Alors que dans l'implémentation régulière des interfaces de fragment, les documents suggèrent que vous pourriez en avoir beaucoup.)

Si vous souhaitez pouvoir effectuer des opérations plus sophistiquées, vous devrez peut-être accéder aux composants internes de Spring Data, auquel cas les opérations suivantes (comme ma solution provisoire pour DATAJPA-422 ):

public class AccountRepositoryImpl implements AccountRepositoryCustom {

    @PersistenceContext
    private EntityManager entityManager;

    private JpaEntityInformation<Account, ?> entityInformation;

    @PostConstruct
    public void postConstruct() {
        this.entityInformation = JpaEntityInformationSupport.getMetadata(Account.class, entityManager);
    }

    @Override
    @Transactional
    public Account saveWithReferenceToOrganisation(Account entity, long referralId) {
        entity.setOrganisation(entityManager.getReference(Organisation.class, organisationId));
        return save(entity);
    }

    private Account save(Account entity) {
        // save in same way as SimpleJpaRepository
        if (entityInformation.isNew(entity)) {
            entityManager.persist(entity);
            return entity;
        } else {
            return entityManager.merge(entity);
        }
    }

}

Compte tenu de votre extrait de code, veuillez noter que vous ne pouvez passer des objets natifs qu'à la méthode findBy ###, disons que vous souhaitez charger une liste de comptes appartenant à certains clients, une solution est de le faire,

 @Query("Select a from Account a where a."#nameoffield"=?1")
      List<Account> findByCustomer(String "#nameoffield");

Faites en sorte que le nom de la table à interroger soit le même que la classe Entity. Pour d'autres implémentations, veuillez consulter ceci

Il y a une autre question à considérer ici. Certaines personnes s'attendent à ce que l'ajout d'une méthode personnalisée à votre référentiel les expose automatiquement en tant que services REST sous le lien '/ search'. Ce n'est malheureusement pas le cas. Spring ne prend pas en charge cela actuellement.

Il s'agit d'une fonctionnalité `` par conception '', Spring Data Rest vérifie explicitement si la méthode est une méthode personnalisée et ne l'expose pas en tant que lien de recherche REST:

private boolean isQueryMethodCandidate(Method method) {    
  return isQueryAnnotationPresentOn(method) || !isCustomMethod(method) && !isBaseClassMethod(method);
}

C'est une question d'Oliver Gierke:

C'est par conception. Les méthodes de référentiel personnalisées ne sont pas des méthodes de requête car elles peuvent implémenter efficacement n'importe quel comportement. Ainsi, il nous est actuellement impossible de décider de la méthode HTTP sous laquelle exposer la méthode. POST serait l'option la plus sûre, mais ce n'est pas conforme aux méthodes de requête génériques (qui reçoivent GET).

Pour plus de détails, consultez ce numéro: https://jira.spring.io/browse/DATAREST-206

Ajout d'un comportement personnalisé à tous les référentiels:

Pour ajouter un comportement personnalisé à tous les référentiels, vous ajoutez d'abord une interface intermédiaire pour déclarer le comportement partagé.

public interface MyRepository <T, ID extends Serializable> extends JpaRepository<T, ID>
{

    void sharedCustomMethod( ID id );
}

Désormais, vos interfaces de référentiel individuelles étendront cette interface intermédiaire au lieu de l'interface de référentiel pour inclure la fonctionnalité déclarée.

Ensuite, créez une implémentation de l'interface intermédiaire qui étend la classe de base du référentiel spécifique à la technologie de persistance. Cette classe agira alors comme une classe de base personnalisée pour les proxys du référentiel.

public class MyRepositoryImpl <T, ID extends Serializable> extends SimpleJpaRepository<T, ID> implements MyRepository<T, ID>
{

    private EntityManager entityManager;

       // There are two constructors to choose from, either can be used.
    public MyRepositoryImpl(Class<T> domainClass, EntityManager entityManager)
    {
        super( domainClass, entityManager );

        // This is the recommended method for accessing inherited class dependencies.
        this.entityManager = entityManager;
    }


    public void sharedCustomMethod( ID id )
    {
        // implementation goes here
    }
}

Spring Data Repositories Partie I. Référence

J'étend le SimpleJpaRepository:

public class ExtendedRepositoryImpl<T extends EntityBean> extends SimpleJpaRepository<T, Long>
    implements ExtendedRepository<T> {

    private final JpaEntityInformation<T, ?> entityInformation;

    private final EntityManager em;

    public ExtendedRepositoryImpl(final JpaEntityInformation<T, ?> entityInformation,
                                                      final EntityManager entityManager) {
       super(entityInformation, entityManager);
       this.entityInformation = entityInformation;
       this.em = entityManager;
    }
}

et ajoute cette classe à @EnableJpaRepositoryries repositoryBaseClass.