Populating an Object from the DB -- Where do you stop?

Question

When getting an object from the DB, should the object's properties also be loaded? There seems to be these approaches.

• Create well-formed, fully-loaded objects.

Pro: No need to check if a property has been loaded; it has. Pass it around and don’t worry about parts of the object not being there.

Con: Where do you stop? If an object has an object, and that object has an object, and that object has 40 objects as properties, etc… Do you load the whole DB? Or do you make a decision in the BLL as to what constitutes a well-formed object, and load those properties?

• Don’t load any properties that are other objects.

Pro: Quick, no loading unnecessary properties.

Con: Code has to be constantly written to check if properties are populated.

• Lazy-loading: only load properties when they are first used.

Pro/Con: Not sure what to say about this approach. It seems intuitively wrong.

Is there another approach? What approach is the best?

And finally, what about properties that can be null? For example, a car may not have a PreviousOwner object. Do you set it to null? An empty PreviousOwner object? Does that property belong in another class then?

Answer 1

There's no easy answer to your question because it depends on what you're trying to achieve.

It looks like you expect a more or less complete object graph to be loaded from the database (i.e. with relationships between multiple object types and the objects themselves stored in the database).

If this is the case, I would look into using the Object Relationship Mapper that's convenient in my language of choice.

As to how much of the object graph is being loaded, the model employed by Apple CoreData's system is objects not yet retrieved are marked as faulty (they call the concept "faulting" - it's described in Limiting the Size of the Object Graph: Faulting. This is a play on the lazy loading concept you described yourself.