spring data jpa: Wie kann man das Repository Interface in 2 Lese/Schreibe Interfaces aufteilen?

[dmike]

Ich stehe gerade auf dem Schlauch. Sowohl [1] als auch [2] erklären wie man das "Repository" Interface auf Lese bzw. Schreib-Interfaces "aufteilen" kann. Das kann doch nicht funktionieren.



So stehts unter [2]

@NoRepositoryBean
public interface ReadOnlyRepository<T, ID extends Serializable> extends Repository<T, ID> {
  T findOne(ID id);
  Iterable<T> findAll();
  Iterable<T> findAll(Sort sort);
  Page<T> findAll(Pageable pageable);
}

public interface CustomerRepository extends ReadOnlyRepository<Customer, Long> {
  // declare query methods here
}

So würde ich das übersetzen:

public interface Globale {

    String getName();

    void setName();
}

public interface ReadOnly extends Globale {

    public String getName();

}

public interface MyInterFace extends ReadOnly {

    String getName();

}

MyInterFace kennt natürlich auch setName() aus dem GlobalI Interface.





[1] InfoQ: Spring Data JPA ? Repositories Done Right @ 25:23

[2] Fine-tuning Spring Data repositories | SpringSource Team Blog

 

[Oliver Gierke]

Mir ist nicht so ganz klar, wie du aus obigem Beispiel unteres ableitest. Ausgangspunkt für den Ansatz bzgl. Der Repository Interfaces ist, dass du sofort alle CRUD Methoden in dein Interface bekommst wenn du von

CrudRepository

erbst. Die Idee ist jetzt also, dass du dir die Methoden raussuchen kannst die du exportieren möchtest und diese signaturgleich in dein Basisinterface legst und dann eben von diesem ableitest.

In deinem Beispiel unten arbeitest du mit Domänenklassen (wo das natürlich grundsätzlich nicht funktioniert weil in dem Repositoryproxy jede Menge Logik steckt, die die aufzurufende Methode auswählt). Aber - deine Domänenklassenhierarchie ist ja auch total anders designed. Da schon das Wurzelinterface die schreibende Methode enthält ist der Keks ja schon gegessen, das tut sie aber in der von dir gezeigten Hierarchie der Repository Interfaces nicht. Im Endeffekt ist dein Wurzelinterface wie

CrudRepository

.

Was ist denn jetzt genau deine Absicht? Die Entitätsklassen unmanipulierbar gestalten?