Motivation
To defer the loading of actual data till it actually asked (on Demand)
Summary
A Lazy Load interrupts this loading process for the moment, leaving a marker in the object structure (for example page number or row count) so that if the data is needed it can be loaded only when it is used.
As many people know, if you're lazy about doing things you'll win when it turns out you don't need to do them at all.
When to Use
Adding Lazy Load does add a little complexity to the program, so prefer not to use it.
It could be preferred when some fields of record set are too big for example LOB like media files.
Implementation
There are four main ways you can implement Lazy Load: lazy initialization, virtual proxy, value holder, and ghost.
Lazy initialization
The basic idea is that every access to the field checks first to see if it's null. If so, it calculates the value of the field before returning the field.
Using lazy initialization is simple, but it does tend to force a dependency between the object and the database. For that reason it works best for Active Record, Table Data Gateway, and Row Data Gateway.
If you're using Data Mapper (165), you'll need an additional layer of indirection, which you can obtain by using a virtual proxy .
A virtual proxy
It is an object that looks like the object that should be in the field, but doesn't actually contain anything. Only when one of its methods is called does it load the correct object from the database.
The bad thing is that you can easily run into a nasty identity problem. Furthermore you can have more than one virtual proxy for the same real object.
Value Holder
With domain classes you can get around these problems by using a value holder.
In this case one object that wraps some other object. To get the underlying object you ask the value holder for its value, but only on the first access does it pull the data from the database.
The disadvantages of the value holder are that the class needs to know that it's present and that you lose the explicitness of strong typing. You can avoid identity problems by ensuring that the value holder is never passed out beyond its owning class.
Ghost
A ghost is the real object in a partial state. When you load the object from the database it contains just its ID.
Whenever you try to access a field it loads its full state. Think of a ghost as an object, where every field is lazy-initialized in one fell swoop, or as a virtual proxy, where the object is its own virtual proxy.
If you use a ghost, you can put it immediately in its Identity Map . This way you maintain identity and avoid all problems due to cyclic references when reading in data.
Related Patterns
TODO
Related Technologies
TODO
Specific Considerations
Limitations of Lazy loading
Inheritance often poses a problem with Lazy Load.
Virtual proxies can suffer from the same problem in statically typed languages.
Danger with Lazy Load is that it can easily cause more database accesses than you need.
Often you'll run into situations where different use cases work best with different varieties of laziness. Some need one subset of the object graph; others need another subset. For maximum efficiency you want to load the right subgraph for the right use case.
The way to deal with this is to have separate database interaction objects for the different use cases. Thus, if you use Data Mapper (165), you may have two order mapper objects: one that loads the line items immediately and one that loads them lazily. The application code chooses the appropriate mapper depending on the use case. A variation on this is to have the same basic loader object but defer to a strategy object to decide the loading pattern. This is a bit more sophisticated, but it can be a better way to factor behavior.
References
Overview Tutorials
TODO
Further References