Losely Coupled Relationships


Friday, October 24, 2003

When you build a database you define relationships between records via foreign keys (hence the 'R' in RDBMS). If you want to access such a related record you have either the option of initiating a second retrieve or to join them right away. This is a very powerful mechanism because you can chop and change the shape of the data you want to receive at the time of the retrieval. Object oriented systems on the other hand do not really allow for this. You get your object and then work your way across the object relations. In an abstract manner this is advantageous because there is no 'assmbly' of your data. In practical terms however there is an impact as soon as you have multiple tiers:

Consider the following relationships:

If you have retrieved your customer and you want to retrieve the postal address you have to traverse these object relationships. Easily done if you have all of them in memory. This is where a prevalence based system for a stand alone application is very powerful. However in most situations you have a multi user application with a prevalence based server. In this case your application design is faced with a quandary. If you retrieve the customer object you need to retrieve all other objects that are linked to it. In this case you would get all kinds of other, unwanted, objects, such as all the other offices and all the other contact details and who knows what else. It is like picking up a spagetti strand and pulling up a whole ball of intertwined noodles.

In practical terms there is only one solution.You can't store your objects with solid relationships as you would design in a proper single tier application. Instead you have to implement the same concept of foreign keys as an RDBMS does.This is what Bamboo Builder creates. I call it 'Loosely coupled relationships'.

The concept works well. However you find that you have to make multiple calls to traverse chains of objects. And your code has to be cognisant of the foreign relations because the prevalence objects generated in Bamboo Builder do not provide you with any information in this respect.

Future Directions

Foreign key relations are stored in the XSD documents used by Bamboo Builder. Hence there is a good argument to extend Bamboo Builder so that for each foreign key the retrieved object offers a method to retrieve the related object(s). e.g. the Company object in the example above would have a method called:

ContactDetail[] GetContactDetails()

which returns all related Contact Details objects. This requires the object to post a call to the prevalence engine. Yet the stored objects at the moment are ignorant of it - which fundamentally is a good principle - however it may need to be broken here.