Records on the rise – Goodbye Lombok
Since the introduction of Java Records in Java 14 (JEP 359), their support in many frameworks has continued to grow. Support is now so great that we should consider banning Lombok from all our projects.
Thoughts on agile software development
Since the introduction of Java Records in Java 14 (JEP 359), their support in many frameworks has continued to grow. Support is now so great that we should consider banning Lombok from all our projects.
This article is a slightly updated English version of the article “REST Endpunkte mit Filtern”.
In addition to sorting and pagination, filtering is a fairly common action on REST endpoints. In contrast to the first two, however, there is no adequate solution for filtering in the Spring Boot framework. With little effort, however, this can be elegantly implemented with the Spring Boot tools.
Im vorherigen Beitrag wurde ein Annotation Processor vorgestellt, mit dem AttributeConverter für Enum Klassen automatisch generiert werden können. Kaum war dieser fertig gestellt, bahnten sich schon die ersten Änderungen an. Die WithEnumConverter Annotation erhält die neuen Attribute ordinal, nullKeyForbidden, exceptionIfMissing und verliert das Attribut representation
In diesem Beitrag finden zwei meiner Steckenpferde hier im Blog zusammen. Es sind die Annotation Processors und die Enums. Beide gemeinsam können ein schon lange bestehendes Problem der Enums auf recht elegante Weise lösen.
Im vorherigen Beitrag wurde ein einfache Lösung für REST Endpunkte mit Filtern vorgestellt. Ein Kritikpunkt an der vorgestellten Implementierung ist die starke Kopplung zwischen dem JPA Repository und dem Filterable. In diesem Bitrag werden wir diesen Ansatz mit dem EntityManager entkoppeln.
Durch den Einsatz von Spring Data JPA in eigenen Projekten können Datenbankaktionen sehr einfach mit Hilfe von Repository Interfaces umgesetzt werden. Alle Zugriffe auf die Entitäten erfolgen über Methoden dieser Schnittstellen. Mit diesen vordefinierten Zugriffsmethoden und der Möglichkeit eigene Zugriffsmethoden zu deklarieren ist ein Großteil der üblichen Anwendungen abgedeckt. Einziger Nachteil dieser Methoden ist ihre feste Definition. Ein alternativer Ansatz, um die Suchen dynamisch zu generieren, verwendet die Schnittstelle Specification.
Nichts ist schlimmer als die Verwendung von alten Datenbanken, die in der Vergangenheit von Hand gepflegt wurden. Häufig ist sehr viel Kreativität gefragt, um auf der existierenden relationalen Struktur, geeignete JPA Entitäten zu erstellen. Ein weiteres Ärgernis, sind dann aber auch die Primärschlüssel der Entität, die in der Vergangenheit nicht durch einen strengen Generator erzeugt wurden, sondern frei gewählt wurden.
Wer ein Attribut in seiner Entity speichern möchte, das ein Set von Enum Werten enthält, kann dies in JPA sehr einfach realisieren. Manchmal fragen einen die Kollegen dann aber doch, ob es nicht andere Wege gibt, ohne eine zusätzliche Tabelle zu verwenden.
Wer als Java Entwickler mit Datenbank Experten zusammenarbeiten darf, kennt deren Hinwendung zu großgeschrieben Bezeichnern. Da heißen die Tabellen dann ANCESTOR_TREE und die Attribute NAME, DESCRIPTION, CREATED_BY. Diese Namenskonvention gilt in Java aber nur für die Namen von Konstanten, weder für die Namen von Klassen noch ihrer Instanz-Attribute.
In den Beiträgen REST in Peace und REST heißt HATEOAS wurde schon auf die Möglichkeiten des HATEOAS Patterns hingewiesen. Die Verlinkung von Resourcen nutzen um innerhalb der Client Anwendung das notwendige Wissen um die Server API zu reduzieren, entkoppelt Systeme und vereinfacht die Entwicklung und Wartung. Auch in diesem Beitrag wird es um die Implementierung … Read more