Fragen zum Design einer EJB (bzw. Business)-Schicht

[JoeMay]

Hallo liebe Gemeinde,

ich habe eine kleine Frage bezüglich des Designs meiner Business-Schicht (habe damit eigentlich kaum Erfahrung, da ich selbst noch in die Schule gehe und keinerlei Ausbildung habe )

Nehmen wir an ich habe eine EE-Applikation mit web-Modul (basierend auf JSF und Klassen für den Zugriff auf die EJBs) und einem EJB-Modul mit der Business- und Peristenzschicht.

Nehmen wir außerdem an, ich habe unter anderem eine Entity-Klasse für eine Bestellung (Fields: Long id, String kunde, Anschrift adresse, @Version ...) (stark vereinfacht natürlich!). Dann habe ich noch eine EJB (stateless) mit den Methoden addBestellung (persistiert Bestellung und macht noch einige andere Dinge mit dieser), editBestellung (zum Bearbeiten einer Bestellung, zum Beispiel Anschrift ändern, etc. ).

Jetzt stellt sich mir die Frage, ob ich die web-Schicht direkt mit den Entitys arbeiten lassen soll und diese dann, nachdem sie bearbeitet wurden, den Bean-Methoden übergeben soll, oder ob ich in den Bean-Methoden als Parameter die neuen Werte schreiben soll (void addBestellung(String kunde, String straße, String hausnummer, String ort, int plz)).

Bei letzterem gibt es das Problem mit dem möglichen Überschreiben von Dateien (Nutzer A überschreibt die gerade von Nutzer B geänderten Daten am Datensatz D, da A nichts von der Änderung wusste (Version-Field in den Entities).

Bei ersteren Methode müsste ich dann noch ggf. Änderungen am Datensatz rückgängig machen, für die der Nutzer keine Editierrechte hat. Dies entfällt durch die @RolesAllowed-Annotations und den richtigen (im Datensatz editierbaren) Parametern.

Ich hoffe, ihr könnt mich da in die richtige Richtung dirigieren

 

[Sym]

Es spricht nichts gegen das Nutzen von Entities in der UI. Es gehört mittlerweile sogar zum "best practice". Die Vorteile sind die Geschwindigkeit (kein unnötiges Mappen zum Beispiel) und das Nachladen von Lazy-Inhalten.

Ich würde allerdings das Schreiben der Entitäten in der Businessschicht belassen und so die Schichten korrekt trennen. Für Dein letztes Problem gibt es mehrere Möglichkeiten. Da solltest Du erst einmal schauen, ob das Problem überhaupt existent ist. Wenn Du z.B. nur Eingabemasken mit Speichern und Abbrechen hast, wird die Form in der Regel beim Abbrechen nicht submittet und somit gibt es kein Update in der DB.

 

[JoeMay]

Ok, danke schonmal soweit
Zum letzten Punkt: Damit meinte ich, dass ich Aenderungen an der Ebntitaet noch vor dem Persistieren rueckgaengig machen muss, wenn der User zum Beispiel die Adresse nicht aendern durfte, meine View ihm das aber (aus welchem Grund auch immer) zum Bearbeiten bereitgestellt hat.
Aber ich denke, ich werde die Entities auf andere, speziell fuer die Schichfenkommunikation erstellte, Objekt mappen

 

[Sym]

Wenn Du eine Save-Methode hast, kannst Du die nicht nur über die Roles sichern, sondern Du kannst Dir auch den eingeloggten User holen und dies dafür direkt prüfen.

 

[JoeMay]

Hi,

das verstehe ich jetzt nicht ganz

Nehmen wir an, die Rolle admin darf alles an der Entity ändern und hat Zugriff auf die Methode saveAll().

Jemand mit der Rolle user darf nur einen Teil der Entity ändern und hat nur Zugriff auf die Methode save().

Damit geht es doch, oder hab ich da was vergessen und muss in den einzelnen Methoden noch prüfen, ob der User tatsächlich in der mit @RolesAllowed deklarierten Rolle ist?

Vielen Dank aber schonmal für die guten Tipps!