Wie behandelt man M: M-Entity-Beziehungen in der Flex/Java-Webanwendung?

Question

Ich kämpfe mit einer Art und Weise zu entwickeln, um effizient verwalten Flex Einheiten, die eine many-to-many-Beziehungen zwischen ihrer JPA/Java Pendants haben. Hier

ist das Problem ... stellen Sie sich einen Film Rezension Web-Anwendung mit zwei Entitäten:

@Entity 
Class Movie { 
List<Viewer> Viewers; 
} 

@Entity 
Class Viewer { 
List<Movie> Movies; 
} 

Beide dieser Einheiten unabhängig voneinander existieren können und beide haben eine 1: M-Beziehung mit der anderen Seite. Die Beziehung gehört nicht wirklich der einen oder anderen Seite. In der Anwendung gibt es Flex-UI's, die manchmal Betrachter basierend auf Filmen und anderen Benutzeroberflächen sehen möchten, die Filme basierend auf Zuschauern sehen wollen.

Momentan sind sowohl die Movies.Viewers als auch die Viewers.Movies Sammlungen lazy von JPA geladen, was gut funktioniert. Das Problem ist, dass jedes Mal, wenn ich einen Zuschauer nach seiner Liste von Filmen frage, alle über den Draht gesendet werden und ich dann innerhalb von Flex mit einer Reihe von Movie-Objekten lande, die (oft nicht immer) die bereits vorhandenen kopieren Dort.

Es scheint im besten Fall ineffizient und könnte wahrscheinlich Fehler verursachen, wenn die doppelten Objekte nicht behandelt werden.

In meiner realen Anwendung habe ich Tonnen dieser Arten von Beziehungen über einige sehr große Objektdiagramme.

Es scheint mir fast, dass die Lazy geladenen Objekt Sammlungen in eifrig geladene Sammlungen von Fremdschlüsseln umgewandelt werden müssen, die zum expliziten Laden von Objekten auf der Flex-Seite der Dinge verwendet werden. Aber das scheint so zu sein, als würde ich einen JPA-Anbieter in Flex schreiben! Ist die richtige Antwort, den Status nie in einer Flex-Anwendung zu speichern? (Yikes) Hilfe !!

Update:

Ich sollte hinzufügen, dass alle über meine Wertobjekte eine UID, die auf der Server-Seite erstellt wird, so konnte ich irgendwie, dass verwenden, um Duplikate auf der Flex Seite zu finden/entfernen. Aber wie?

Answer 1

Es gibt nichts, was Sie tun können, wenn das Backend neue Instanzen derselben Objekte zurückgibt, die Sie bereits im Speicher haben. Wenn mehrere Instanzen auf dieselben Entitäten verweisen (basierend auf dem Wert, nicht auf dem Speicherort), kann dies beim Suchen und Filtern zu einigen unerwarteten Ergebnissen führen. Das liegt daran, dass ein einfaches === für 2 verschiedene Entitäten nicht immer wahr ist, was scheinbar dieselbe Entität ist, weil sie sich auf 2 verschiedene Objekte im Speicher beziehen.

Ich würde vorschlagen, benutzerdefinierte Gleichheitsmethoden zu Ihren Entitäten hinzuzufügen, anstatt sich auf === zu verlassen. Im Fall von Entitäten basiert die Gleichheit auf der ID, die höchstwahrscheinlich auch die Datenbank-ID ist. Bei Wertobjekten basiert die Gleichheit auf dem Status der Objekte.

Auch würde ich nicht versuchen, viel Staat auf dem Client zu halten. Ich weiß, dass dies eine attraktive Lösung ist und dass sie in einigen der Flex-Framework-Architekturen beworben wird, da Sie schließlich einen Rich-Client erstellen, aber nach meiner Erfahrung führt dies zu vielen Szenarien, in denen Daten veraltet sind und Probleme verursachen die Straße runter. Wenn Sie nicht mit verwalteten Daten arbeiten (wie in LCDS), würde ich lieber das Backend abfragen, anstatt den Client-Status zu verwenden.

Als letzte Anmerkung: Die m-m-Beziehung ist meiner Meinung nach ein Datenbankimplementierungsdetail und sollte nicht in die Domäne von Client und Server übersetzt werden.Ich würde viel lieber Service-Methoden erstellen, die die Filme von einem Betrachter abfragen oder umgekehrt. Es gibt ein gutes Material zu diesem Thema in den DDD-Schriften von Eric Evans.

Answer 2

LCDS versucht, dieses Problem für Sie zu lösen, indem Sie Datenmanagement verwenden - aber ich bin mir nicht sicher, ob es noch auf der Roadmap ist oder nicht. Wenn Sie also den direkten Ansatz verwenden (versuchen, das Modell mit allen Beziehungen auf dem Client zu duplizieren), könnten Sie wahrscheinlich damit beginnen, Ihren eigenen Entity Manager in Flex zu schreiben, vorausgesetzt, Sie haben unbegrenzte Zeit.

In meinem Fall verwende ich BlazeDS und ich fange an, einfachere Objekte für den Client zu erstellen. Wenn ich zum Beispiel alle Filme benötigen würde, würde ich etwas wie ein MovieVO-Transportobjekt erstellen und ich würde die Liste der Objekte aus der Liste der Filme erstellen. Abhängig von der Spezifikation werde ich dem MovieVO weitere Informationen hinzufügen (wie eine Variable, die die Anzahl der Zuschauer zählt oder eine vereinfachte Liste von Zuschauern). Grundsätzlich vereinfache ich das Modell auf dem Client sehr. Der Nachteil ist, dass ich viel Klebercode schreiben/ändern muss.

Ich bin sehr neugierig auf andere Ansätze, vor allem von Entwicklern, die weborb/graniteds verwenden.