I am struggling to come up with a way to efficiently manage Flex entities that have a many-to-many relationships between their JPA/Java counter parts.
Here is the problem...imagine a movie review web application with two entities:
@Entity
Class Movie {
List<Viewer> Viewers;
}
@Entity
Class Viewer {
List<Movie> Movies;
}
Both of these entities can exist independently of each other and both have a 1:M relationship with the other. The relationship is not really owned by one side or the other.
Within the application there are Flex UI's that sometimes want to see viewers based on movies and other UI's that want to see movies based on viewers.
Currently both the Movies.Viewers and Viewers.Movies collections are lazy loaded by JPA which works fine. The problem is that every time I ask a viewer for it's list of movies, then they all get sent over the wire and then within Flex I end up with a bunch of Movie objects that (often, not always) duplicate the ones I already have there.
It seems inefficient at best and could likely cause errors if the duplicate objects are not dealt with.
In my real application I have tons of these types of relationships all over some very large object graphs.
It almost seems to me that the lazy loaded object collections need to be turned into eagerly loaded collections of foreign keys which are used to explicitly load objects on the Flex side of things. But this seems like I am writing a JPA provider in Flex! Is the correct answer to never store state in a Flex application? (Yikes) HELP!!
Update:
I should add that all my value objects have a UID that is created on the server side, so I could somehow use that to find/remove duplicates on the Flex side. But how?
There is nothing you can do about the backend returning new instances of the same objects you already have in memory. Having multiple instances refering to the same entities (based on value, not memory location) can lead to some unexpected results though when searching and filtering. That is because a simple === on 2 different entities will not always be true on what seems to be the same entity because they refer to 2 different objects in memory.
I would suggest to add custom equality methods to your entities instead of relying on ===. In the case of entities, the equality will be based on the id, which is most likely also the database id. In case of value objects, equality is based on the state of the objects.
Also, I would not try to keep much state on the client. I know this seems like an attractive solution and that it is promoted in some of the Flex architetural frameworks, since after all you are building a rich client, but in my experience this leads to many scenarios where data is out of date and causes problems further down the road. Unless you are working with managed data (as in LCDS) I would prefer querying the backend instead of using the client state.
As a last note: the m-m relation is a database implementation detail in my opinion and should not be translated into the domain of both client and server. I would much rather create service methods that query the movies by a viewer or vice versa. There is some good material on this topic in the DDD writings of Eric Evans.