Soll in JPA ein Repository pro Tabelle vorhanden sein?

Question

Soll in JPA ein Repository pro Tabelle vorhanden sein? Wenn nicht, wie lösen Sie die Generika in der Repository-Datenbank auf?

Zum Beispiel ist unten ein StoreRepository. Es handhabt CRUD Operationen auf dem Objekt Store. Wenn ich möchte, dass das Repository auch ein StoreEvent Objekt speichert, wie würde ich die untenstehende Schnittstelle ändern, um beide Objekte unterzubringen?

@Repository 
public interface StoreRepository extends JpaRepository<Store, String> { 
    public Store findByGuid(String guid); 
} 

Answer 1

Als Repository ist ein Konzept von Domain Driven Design abgeleitet, das Denken über Datenbanktabellen der falsche Ansatz ist. Per Definition greifen Sie auf Aggregatstämme aus einem Repository zu. Effektiv simuliert ein Repository eine Sammlung von diesen.

Nun, was bildet ein Aggregat Wurzel? Wahrscheinlich noch interessanter: was nicht? Das hängt natürlich stark von Ihrer Domain ab, aber lassen Sie mich Ihnen hier ein Beispiel geben. Ein Order, der LineItems enthält, wird normalerweise als ein aggregierter Stamm modelliert. Dies liegt an der Zusammensetzung der Order. Eine LineItem würde ohne eine umgebende Order nicht existieren.

Normalerweise sind die Persistenz Zugriffsmechanismen sollten die Domäne Prinzipien folgen. Daher würden Sie sowohl Order als auch LineItem als @Entity Klassen modellieren, aber nur eine OrderRepository als Form des Aggregatsstamms erstellen und die Konsistenzregeln innerhalb des Objektdiagramms effektiv steuern.

Wir auch stark empfehlen nicht die Speicher spezifische Repository Basis-Interfaces, wie sie zu verwenden - wie der Name schon sagt - Speicher Besonderheiten aussetzen (z flush()) zu den Kunden, die das nicht bewusst, wenn möglich sein sollte. Lesen Sie mehr dazu in meiner Antwort here.