File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Associating objects via object references versus identity map lookups Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Associating objects via object references versus identity map lookups" Watch "Associating objects via object references versus identity map lookups" New topic
Author

Associating objects via object references versus identity map lookups

Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
Business Entity A is related to zero or more Business Entity B's.

In our relational db, table A, has a primary, numeric id, which is also a foreign key in table B.

We have a desktop gui application that loads all the A's and B's and allows certain manipulations of them. The client uses a server and there can be many clients. The server broadcasts updates when clients update A's or B's, the clients process these updates and keep their object models up to date. In short, the model's are kept up-to-date.
The client app supports various operations such as,
CRUD operations on A's and B's.
Displaying a tree of A's and B's (where B's are the leaves). Clicking on a B, shows all the relevent C's (a B can have zero or more C's, exactly the same configuration as A->B).

I'm unsure whether it's better to model the relationship between A and B as an object reference, or alternatively, to do a look-up on the data-sink of B's.
Option1 :


Option2 :


In option 2, BSink is an Object that maintains all the B's, listening to updates from the server and applying them. getBSink() somehow returns the correct BSink object.

I started out with option 1, as it seemed more "natural". However I'm beginning to think that option 2 has some merit.
My main problem with option 1, is that I wanted to make my A and B class immutable. If I get an update for B, I have to
create a new B
create a new A, with a new bs attribute
send out an update to the gui code, so it can reflect this change

This seems fairly clunky - an update to B shouldn't need to cause an A update to occur. This is worse in the situation where B's have a relationship with C's and C's have a relationship with D's etc. A change in D, means I have to replace a large portion of my object model.
Option 2 appears to get round this, my objects can still be immutable and A.getBs() will always return the correct (ie most up-to-date) version of the related B's.

So that's where I am, I hope it made *some* sense ! I'm currently thinking about moving to option 2. It seems quite attractive, but I'm also wondering if I missing some finer details...anyone got any insight ?

thanks,
D.
[ September 15, 2004: Message edited by: Don Kiddick ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
A few kinda random thoughts ...

1) Why should A ever give out its B's? What is somebody going to do with them? If A owns the Bs shouldn't A be doing that? Could you replace

with

Of course it's never quite that easy, but maybe it will get you thinking.


2) I used a sink much like you described for lazy instantiation. You could imagine that all instances of B are in the sink. Ask for one by id and you get it. What you don't know is that Bs are not really in the sink until you ask for them. We definitely considered it an architectural compromise to OO goodness.

3) "A change in D, means I have to replace a large portion of my object model." That scares me. If you want to talk about that maybe we can help reduce some of these dependencies.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    1
Option 1 is more object oriented and thus will probably make it easier to write the client code that has to deal with the business entities. On the other hand, Option 2 will make processing updates from the server much easier. Selecting an option may depend on which kind of code you're likely to have to write more of.

Option 1, properly implemented, may be more efficient as well, but that probably doesn't matter in the client.

If you do use Option 1, I'd suggest two things: (1) use Java Collections rather than arrays, and (2) give up on immutability. If you want to keep immutability, I think you may end up rebuilding the entire data set each time you get a server update.

Is there any upstream updating from the client to the server? If there is, I think you'll want first to decide how to handle the situation when a client tries to update something based on stale information before you make decisions on how to handle updates from the server.
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
Originally posted by Stan James:

1) Why should A ever give out its B's? What is somebody going to do with them? If A owns the Bs shouldn't A be doing that? Could you replace


Ask don't tell, right ? One of things I do is display all the A's and B's in JTree, so I think I need to go from A -> B's.

Originally posted by Stan James:

2) I used a sink much like you described for lazy instantiation. You could imagine that all instances of B are in the sink. Ask for one by id and you get it. What you don't know is that Bs are not really in the sink until you ask for them. We definitely considered it an architectural compromise to OO goodness.



We do similar things in some of our sinks. I'm not sure I understand what OO-goodness your losing out on though ?

Originally posted by Stan James:

3) "A change in D, means I have to replace a large portion of my object model." That scares me. If you want to talk about that maybe we can help reduce some of these dependencies.


Yep, it's smelly isn't it? Actually what I did to avoid this was to make the Bs attribute of A mutable (ie settable).

After reading the comments here and doing a bit more research, I feel my aim of making my A and B classes immutable was misplaced. I now think that they are reference objects as opposed to value objects. This means that immutablity isn't needed. I'm quite happy with my design, now as my classes are as immutable as possible, with mutability where required.

D.
[ September 18, 2004: Message edited by: Don Kiddick ]
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
Originally posted by Warren Dew:
Option 1 is more object oriented and thus will probably make it easier to write the client code that has to deal with the business entities.


Why is option 1 more object orientated, my gut tells me the same but why ?

Originally posted by Warren Dew:

If you do use Option 1, I'd suggest two things: (1) use Java Collections rather than arrays, and (2) give up on immutability. If you want to keep immutability, I think you may end up rebuilding the entire data set each time you get a server update.


(1)Yep, we do use collections, the arrays in the example were for clarity.
(2)That's what we're doing now.

Stan/Warren thanks for replying, my mind feels much clearer now.
D.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Associating objects via object references versus identity map lookups
 
Similar Threads
About Overridden methods...
Lazy relationships become loaded after EntityManager closes
BiddingModel in Java
NullPointer with EntityManager in Entity Bean
Inheritance in Bytecode!