Repositories refaktorieren

[phlobbi]

Im Moment wird in den Repositories viel Code doppelt verwendet. Daher die Frage, ob es Möglichkeiten gibt, solche Dopplungen wenigstens etwas zu reduzieren.

Antwortet dazu am Besten hier im Issue. Wenn es keine Möglichkeiten gibt ist das nicht weiter schlimm, dann mach ich das hier wieder zu.

[KmerPro237]

1- Die delete() und persist() Methoden in allen Repositoryklassen unterschieden sich nur mit einem bzw zwei Codezeilen. Ich frage mich jetzt, ob wir die Persistence einer Entität nicht in zwei Methoden unterteilen können und dann diese aufrufen, wenn sie benötigt werden. D.h Eine Methoden die die Transaction öffnet und eine andere die sie schließt. Jetzt könnte in der Mitte oder irgendwo anders etwas stehen (wie delete Funtionen), wenn benötigt.

2- Könnten wir nicht die removeOrphan() Methoden bei der Car- und CustomerRepository generisch implementieren?

3- Ich frage mich jetzt, ob wir bei Punkt-1 eine Fassadeklasse nicht erstellen könnten. Falls die Erstellung eines Persistence-Unit in 2 Methoden implementierbar ist, könnten wir so vorgehen und die Methoden in alle anderen Klassen aufrufen. Außerdem könnten wir bei Punkt-2 Wildcards anwenden und die Typdefinition erst bei der Implementierung durchführen.

[gitroba]

@KmerPro237 @phlobbi Ich hab mal probeweise alle Funtionalitäten des Booking-Repo in ein neues, zentrales Repo ausgelagert (außer orphanRemoval). Falls das in der Form Zustimmung findet, könnte man dann die restlichen Repos ähnlich auslagern. Hab dazu neben Generics auch ein neues Interface gemacht, von dem die anderen Interfaces erben, damit das eben so zentral steuerbar wird.