views:

199

answers:

2

I'm stuck with the following scenario. It has a code smell, that I'm not happy with, but resolutions to it seems to be as complex, but just in different ways.

I have a scene graph representing business objects. I've designed it so that the business objects themselves are as simple as could be. They're practically POJOs.

Now, 1 entity might be displayed in multiple regions of the scene graph by different nodes.

When the entity changes, all relevant scene graph nodes should change.

I'm hesitant to use the observer pattern on all my entities since I have over 50000 entities on screen at one time.

Since all changes are initiated from the view, right now I'm recursing over the scene graph and forcing a reload of all nodes associated with the changed entity. Doesn't feel right though.

Any suggestions on how this could be done better?

+2  A: 

The entities should post their updates into a single queue, which can then be polled by the object responsible for updating the view.

Jonathan Feinberg
What is the difference between the Observer being notified directly vs Observer polling a queue?
Thimmayya
The OP wants an alternative to having each observer register its interest in each of 50,000 objects. I'm not sure what your comment refers to.
Jonathan Feinberg
I could not figure out the benefit of the observables(entities) posting their updates to a queue vs posting it directly to the observer. It seems to me that the queue is replacing the final observer by becoming an intermediary, but the queue now functions as a logical observer anyways.
Thimmayya
Again, you have not understood the OP. Read it again.
Jonathan Feinberg
+3  A: 

Business Object == Entity? You have 50k of them represented as nodes on the screen, with some entities having more than one node. A user action chages the state of the entity and hence some nodes must be updated. But of course Entities don't know about nodes.

I would have proxy object wrapping the Entity. He understands the relationship to the Nodes. Updates to the entity go via him, hence he can complete the update and then notify the relevent nodes. Effectively this avoids having to iterate the set of nodes looking for updates.

djna