Pattern für Benutzer-Gruppen, RMI

[tuxedo]

Hallo zusammen,

ich grüble schon seit längerem über die Frage, ob es für sowas (siehe unten) ein Pattern gibt. Google und Co. haben mich da nicht wirklich weiter gebracht, mir fehlen irgendie die passenden Suchbegriffe.

Es geht im folgendes:

Man hat eine Serveranwendung (völlig abstrakt bertrachtet, keine spezielle Technologie) die Entitäten hat, die in 1:n oder n:m Beziehung zueinander stehen können. Der Server bietet ein API an, mit dem es Client ermöglicht wird die Entitäten zu lesen, verändern und wieder zu schreiben.

Nur mal angenommen die API die der Server anbietet ist zum administrieren von Benutzern und Gruppen. Ein oder mehr Benutzer kann in einer oder mehreren Gruppen sein. Klassisch n:m

Wenn man sich als Client nun eine Gruppe vom Server holt, welche Variante wäre "gängig"?

a) Das Gruppen-Objekt hat sowas wie eine "public List<User> getUsers()" Methode
b) Das Gruppen-Objekt selbst kann man nicht nach Usern fragen. Man muss über das API gehen. Etwa so: userMgt.getUsers(myGroup) --> liefert List<Users>

Bei a) sehe ich das Problem, dass man ohne EAGER LOADING nicht auskommt. Außer die Client-Server-Kommunikation ist so intelligent und managed das Nachladen über Rechnergrenzen hinweg automatisch im Hintergrund. Von daher würde ich mal auf b) tippen.

Kennt jemand ein Buch oder eine Webseite die sich nicht nur mit den Basics bzgl "wie lese und schreibe ich Entitäten" oder "Wie benutze ich RMI/Remoting/...", sondern eher "Wie schreibe ich ein sinnvolles API das mit Entities/verketten Pojos über Servergrenzen hinweg umgehen kann?"

Gruß
Alex

 

[faetzminator]

a) Das Gruppen-Objekt hat sowas wie eine "public List<User> getUsers()" Methode
b) Das Gruppen-Objekt selbst kann man nicht nach Usern fragen. Man muss über das API gehen. Etwa so: userMgt.getUsers(myGroup) --> liefert List<Users>

Ob das nun so oder so entwickelt wurde, macht schlussendlich keinen Unterschied, da im einen Fall [c]myGroup.getUsers()[/c] bzw. im anderen Fall [c]userMgt.getUsers(this)[/c] aufgerufen werden könnte.
Da muss geprüft werden, ob die Daten bereits vorhanden sind oder noch geladen werden müssen.

 

[mvitz]

Geht beides und ist meiner Meinung nach ein wenig Geschmackssache. Im Falle A sollte man dann in der Tat Eager/Lazy Loading betrachten und einsetzen, wenn es Sinn macht.

 

[tuxedo]

So hab ich mir das auch gedacht. Wundert mich nur ein wenig dass das Thema wenig bis gar nicht dokumentiert ist. Hätte schon erwartet dass ich in dem einen oder anderen Buch zum Thema Remoting oder JPA so eine Art "best practice" finde. Aber nix dergleichen. Hab hier noch ein API Design Buch rumliegen. Werde das (nochmal) zu rate ziehen. Vielleicht hab ich ja was übersehen...

 

[fastjack]

Ich finde A am verständlichsten.

 

[tuxedo]

Hmmpf, ich weiß dass mein Titel nicht der beste war, aber der der jetzt über diesem Thread steht passt auch nicht besser, da es hier weder explizit um Benutzer und Gruppen, noch um RMI geht. Das "Problem" ist eher allgemeiner Natur.

Aber gut, *back-to-topic":

(a) hab ich anfangs auch preferiert. Aber da ist noch das Problem mit dem Lazy-Loading. Auf Serverseite muss ich die Entitäten von der Persistenzschicht abkoppeln bevor ich sie zum Client schicke. Ich kann, am beispiel JPA und RMI, nicht einfach die Entität so wie sie ist zum Client übertragen. Der Client weiß ja in der Regel nix von der Persistenzschicht. Ergo muss ich die Entitäten abkoppeln. Und einmal abgekoppelt ist nix mehr mit LazyLoading.

Hab mich mittlerweile mit (b) angefreundet. Aber vielleicht finde ich ja noch c) ... mal schauen.

- Alex