Java lernen

Spring Spring Boot mit Rest, JPA und Frontend

Diskutiere Spring Boot mit Rest, JPA und Frontend im Allgemeines EE Forum; Hallo zusammen, ich habe Spring Boot mit JPA und Rest mal angeschaut, finds auch richtig cool. Mir fehlt allgemein nur der Faden wie ich das...

  1. lam_tr
    lam_tr Mitglied
    Hallo zusammen,

    ich habe Spring Boot mit JPA und Rest mal angeschaut, finds auch richtig cool. Mir fehlt allgemein nur der Faden wie ich das aufteilen soll, sodass meine Anwendung nicht monolytisch wird.

    Nehmen wir ein Adressbuch als Beispiel.

    Ich habe vor den Server Teil in ein Spring Boot Projekt zu Packen mit Rest und JPA. An der Stelle gibt es folgende Komponente:
    - RestPersonService // Rest Schnittstelle
    - PersonRepository // Schnittstelle zur Datenbank

    Ein normales Java Projekt mit Model (Shared Projekt), das zum Beispiel in der PersonRepository und Frontend (JavaFX) benutzt wird:
    - Person

    Zweites Spring Boot Projekt zum Darstellen der Oberfläche, das den Server Spring Boot Projekt und das Model Java Projekt im Classpath inkludiert.

    Ist diese Vorgehensweise ok?
    Ohne das Shared Projekt, müsste ich das Server Projekt direkt ansprechen um das Modell in der Oberfläche abbilden zu können.

    Habt ihr da Tipps für mich.

    Viele Grüße
    lam
     
  2. dzim
    dzim Bekanntes Mitglied
    Nutze Maven- oder Gradle-Module (bei Gradle nennt es sich "Projekte", glaub ich).
    Ich hab auf Arbeit ein grösseres (Maven-)Projekt gegenwärtig so aufgeteilt:

    • Maven-Parent für einige festgelegt Versionen. Interessant für Projekte, die *nicht* explizit Spring Boot als Parent haben - also eigentlich nur das Modul "model" ... hat das Parent-Prinzip bei mir etwas ad-absurdum geführt, aber egal.
    Hier die Module:
    • model - geteiltes Modell für *alle* Module, z.B. JSON-Pojos

    • db-service-postgres - JPA Entities für den DB-Zugriff auf Postgres
    • db-service-common - es gibt in dem Projekt zwei Server, einen intern ohne Zugriffsbeschränkung und einen externen mit Spring Security für Rollen-/Userbasierten Zugriff auf bestimmte Daten
    • db-service - interner ReST-Service
    • db-service-ui - externer ReST-Service (Kotlin! \o/ )

    • data-access - Schnittstelle für den Zugriff auf den "db-service"
    • controller, worker, validator - jeweils recht spezielle, durch "data-access" aber sehr schlanke Member eines eigenen Hazelcast-Clusters
    Ein konkretes UI war vom speziellen Kunden nicht gewünscht, daher haben wir das nicht. Wir werden aber wohl eines für einfachere Admin-Zwecke bauen...
    Das wird dann aber als separates "static" Web-Projekt erstellt (vermutlich mit Angular) und auf einem nginx, caddy, o.ä. deployed.

    Man könnte aber auch "data-access" verwenden (oder es noch etwas aufspalten, da bei mir jetzt auch noch Cluster-Zeug enthalten ist), um eine JavaFX-Anwendung mit Spring Boot darüber an den Server zu verbinden (jedoch mit dem Risiko von Vollzugriff auf z.T. Daten, die man nicht von Menschen ändern lassen will).
    Auf alle Fälle kann man aber das "model" verwenden und könnte "data-access" als Vorlage nehmen, um den "db-service-ui" anzusprechen und damit sein Tool aufbauen. Könntest auch noch RxJava oder oder so in den Ring werfen.

    Grundsätzlich ist also nur wichtig, dass du deinen Code in sinnvolle Module aufteilst, so dass du Zeug teilen/wiederverwenden kannst. Das beispielhafte Projekt hier ist schon etwas arg ausgeartet und ich würde dort kein weiteres UI-Projekt mehr reinstopfen, aber dann müsstest du halt so etwas wie "model" in ein separates Projekt auslagern. In deinem Fall aber würde es sicher noch gehen. Einfach ausprobieren!
     
    lam_tr gefällt das.
  3. looparda
    looparda Aktives Mitglied
    Ein paar Fragen aus Eigeninteresse, aber trotzdem nah am Thema:
    @dzim
    Liegen im db-service Entities (mit ORM-Annotationen o.ä.) und im model wirklich die Applikationsmodelle, auf denen die Business-Logik arbeitet? Wenn ja, wie macht ihr das Mapping zwischen diesen beiden Typen? Und benutzt ihr JPA/Hibernate oder ein anderes ORM?
     
  4. dzim
    dzim Bekanntes Mitglied
    Im "db-service-postgres" sind die Entities enthalten. Im Nachhinein würde ich jedoch nicht mehr JPA verwenden sondern eher so etwas wie JOOQ, denn in speziellen Grenzfällen ist mir JPA noch etwas zu langsam (was auch sicher daran liegt, dass ich kein Profi damit bin).
    "model" enthält die DTOs, also die die Transferobjekte. Damit ein Mapping zwischen Entity und DTO so einfach wie möglich geht, habe ich mir da eine Klasse/API geschrieben, die Massiv auf Reflection setzt, um die Modelle zu überführen.
    Sprich: innerhalb der "db-service-*" Module setze ich auf Entities, mit den "Consumern" (siehe "data-access" und die Cluster-Member) setze ich dagegen auf die DTOs.
    Ist das ein guter Weg? Keine Ahnung! Er funktioniert gut, aber ist sicher etwas umständlich...

    Man muss dazu sagen: Ich habe mehr oder weniger den gesamten Core und die Struktur des Projekts "verbrochen", ein Kollege von mir hat dann nur noch APIs in den "worker" und "validator" verwendet und muss nur in wenigen Ausnahmefällen sich in die Untiefen der anderen Module verirren. Er fand es aber praktisch, wie ich es aufgebaut hab.
    Aber wie gesagt: Mit JPA bin ich dabei nicht warm geworden...
    Was verwendest du?
     
  5. looparda
    looparda Aktives Mitglied
    Ich benutzte Java mit Datenbank nur in einem Hobbyprojekt, welches aber durch folgendes eingeschlafen ist:
    Ich habe Hibernate nicht auf die Reihe bekommen. Erst habe ich die Annotation-Verseuchten Entities in meiner JavaFX Applikation benutzt. Bei Beziehungen wurde es dann jedoch knifflig und ich bekam ständig Exceptions oder Probleme mit Objektgleichheit in Collections.
    Später habe ich dann Beans in der JavaFX Applikation benutzt und sie per Hand zu den JPA-Entities gemappt. Eine einfache update Funktion war jedoch auch nicht machbar für mich.
    Usecase:
    Ein Projekt hat mehrere Personen. Personen können mehrere Adressen zugeordnet werden.
    Jemand editiert über die GUI ein Projekt über Projekte > "Projekt A" > Personen > "Person A" > Adressen und
    benennt Projekt zu "Projekt X", fügt eine Person hinzu, löscht eine weitere Person und bearbeitet die Adresse einer Person. Das Projekt-Objekt wird dann zur Datenhaltung weitergereicht an eine update-Funktion.
    In der update-Funktion darf man sich dann im Mapping abrackern an allen CRUD-Kombinationen*beliebige Verschachtelungs-Tiefe (wurde das jetzt bearbeitet oder hinzugefügt? soll das jetzt gelöscht werden, weil es nicht mehr in der Bean Collection ist, aber noch in der Datenbank (und falls ja, sollen auch die Kinder gelöscht werden?(muss ich dafür das Repository des Typs des Kind-Entities bitten sich um die Löschung zu kümmern? (Wie komme ich dynamisch und Typsicher an das Repsoitory?)))?) und dann auch noch verschachtelt und generisch. Hab ich auch nicht hinbekommen und da sehe ich den Vorteil eines ORM nicht mehr. Hibernate sieht super toll aus, sofern man 1:n, n:m Beziehungen benutzt aber sobald man eine 1:nm:1 Beziehung mit Extra Attribut an der Beziehung hat wird es hässlich.
    Ich denke das artet hier aber dann doch aus, wenn wir weiter Richtung Hibernate reden.
     
  6. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    Bisher war das gefühlt in jedem Projekt anders aufgeteilt :D

    Im aktuellsten siehts etwa so aus und klappt auch bisher ganz gut:

    * parent
    Projekt mit Build-Config und Abhängigkeiten, die alle brauchen, zB Tests etc.

    * domain
    Alles zur Domain gehörende.
    Im wesentlichen Entitys (mit JAP, allerdings *nur* Annotationen), Services und Repository-Interfaces (an den Namenskonventionen von Spring orientiert, allerdings nicht die Spring-Repos erweiternd). Das ganze Projekt hat keinerlei Spring-Abhängigkeit. Im wesentlichen das M aus MVC ;)

    * persistance
    Enthält im wesentlichen nur Interfaces, die die Repo-Interfaces aus domain und das Spring-Repository-Interface extenden. Allerdings bin ich noch nicht sicher, wie viel Sinn das hat...

    * rest & web
    Enthält alle Controller, entweder als RestController oder geben entsprechende Views zurück. Nutze zT DTO etc, um die Domain-Objekte nach außen noch mal zu kapseln und ins passende Format zu bringen. Das Mapping zwischen Entity-DTO wird per Hand gemacht, DTOs sind aber recht flach und das ist damit nicht allzu kompliziert
     
    lam_tr gefällt das.
  7. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    u.U. wäre etwas in Richtung Domain-Driven-Design einen Blick wert.

    Solche Dinge finde ich persönlich mit JPA + Spring Data recht einfach zu lösen.

    Aus dem Controller kommt das "Name ändern, Person hinzufügen, Person löschen"-Event. Projekt wird geladen (oder ist es schon), dieses führt die Änderungen durch, und danach wird gespeichert. Irgendwelche Mappings per Hand etc würde ich vermeiden. Welches Repo zuständig ist, kann man nach DDD recht gut modellieren.
     
  8. looparda
    looparda Aktives Mitglied
    Mich würde so eine Lösung sehr interessieren und ich würde JPA/Hibernate echt gern in den Griff bekommen. Können wir das vielleicht irgendwo besprechen? Ich habe ein Mini-Projekt, welches noch meine genannten Probleme beinhaltet aber man könnte dies vielleicht als Basis nehmen und zusammen umbauen.
     
  9. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    liegt's bei Github oder so? Gern auch n eigener Post dazu ;)
     
  10. dzim
    dzim Bekanntes Mitglied
    Also wie ich schon sagte: Ich werde auch nicht zu 100% warm mit JPA. Ich habe ein paar der abstruseren Dinge in den Griff bekommen (z.B. Sequenzen bei Postgres... Die nötigen Annotationen... Grausig!), an anderen aber bin ich gescheitert (bestimmte Projektionen), so dass ich am Ende einige recht komplexe Anfragen mit native Queries über den EntityManager selbst gebaut habe (komplexe und sehr variable Anfragen für bestimmte Filter, die sonst statt einem solchen Query viele verschiedene über die Entities bedeutet hätten.
    Wie gesagt: Ich werde JPA/Hibernate für ein solches Projekt *nicht* noch einmal verwenden, sondern nur noch bei kleineren Sachen. Oder sonst einfach Spring Data für NoSQL (MongoDB, etc.) verwenden.

    @mrBrown - deine Aufteilung klingt logisch und gut, eventuell kann ich euch ja mal eine etwas bereinigte Variante meines ModelConverters zukommen lassen, da muss ich aber erst mal meinen Chef fragen, ob das OK ist... Denn manuelles Mapping genügt zwar sicher, ist aber auch recht aufwendig zu warten, wenn man etwas umstellt, oder?
     
Die Seite wird geladen...

Spring Boot mit Rest, JPA und Frontend - Ähnliche Themen

Authentifizieren mit SpringBoot
Authentifizieren mit SpringBoot im Forum Netzwerkprogrammierung
Spring Boot Microservices und Entitäten
Spring Boot Microservices und Entitäten im Forum Application Tier
Spring Boot javax.mail
Spring Boot javax.mail im Forum Application Tier
Spring Boot: Logfiles wie organisieren?
Spring Boot: Logfiles wie organisieren? im Forum Web Tier
Spring Boot GET
Spring Boot GET im Forum Web Tier
Thema: Spring Boot mit Rest, JPA und Frontend