Lazy loading is a familiar pattern for hydrating business objects but has the drawback of being expensive when many objects need to retrieved (through many SQL queries).
In a situation where there are perhaps 20 classes of object each with only 5 to 100 instances of each class, it may make sense to load each of the instances of each of the classes in one go. However linking these classes might be best done as required (hence 'lazy linking') especially if there are large numbers of interconnections to sort out. I am assuming the objects are cached once loaded and indexed on their ID. I am also referring to foreign key mapping (in Fowler's parlance) rather than association table mapping.
I have not found reference to this kind of pattern and am checking here to see if anyone is aware of any work relating to this or has any comments.
Thanks for any contributions
Lazy linking pattern
ColinD
I see similar issues at play here to a system I'm designing (see link for my questions about managing large object structures)
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=254907&SiteID=1
Much of the tradition approches to object methodology fail with large object structures, especially if executed in a serviced component environment.
I agree that a pre-load is much more efficient for large structures, but why not also pre-link. (Which is what I'm planning on doing)
The only advantage to the lazy link for pre-loaded objects, I can see, would be if you had a generic pre-load function that return more data than required for a given process, then lazy-link your way through at run-time to isolate the relevant data, which would require less methods exposed to the consuming layer/service/etc.
However to gain efficiency of a pre-load it would be better off being as lean and mean as possible so the linking pattern would be static for that method and no efficiency gained from delaying it, but more specialised methods exposed.
barbbayne
Roygana
Yes, I agree with your serialized LOB observation.
The approach may be more generally applicable than it at first appears as a good few applications have quite a number of classes or class hierarchies with just a few objects in them, but some others with a large number. Perhaps this is most likely when as much data as possible is pushed outside of the application into a database. No doubt some guys somewhere have explored it in depth.
Incidentally I failed to mention that the disadvantage of the approach is the extra time taken to look up the link from ID to object (typically via a hashtable). This step is not necessary if linking is done at object load time.
Mike
shinji360
You probably won't find this approach as your situation is relatively special (small number of objects with a lot of connections)
The approach you are taking is sort of a plug-in pattern (wiring in run-time) - in any event what's important is not what name does it have, but whether or not it fits your requirements (scalability, performance etc.)
By the way another approach you can take if you have few objects with a lot of interactions is "serialized LOB" http://patternshare.org/default.aspx/Home.MF.SerializedLOB
HTH,
Arnon
Nfrf
Thanks for the reply. All Fowler's example of lazy load (including ghosts, value holder, virtual proxy) delay loading of the object. I am looking here at the possibility of loading all (of a relatively small population) of the objects in one go for maximum efficiency, but only creating the links between objects as required (in a lazy fashion).
Initial trials suggest that a major advantage (in addition to efficiency) is simple code as the loads are simple SQL fetches (with few joins) and no special 'coordinating' loading methods are required. Property holders which are filled with references to the (already loaded) objects as required.
As I mentioned this only seems easy to do with foreign key mapping and particularly in the case where there is a mapping from one object to one other object.
talon121
The problem is that it also makes your server stateul, and since this creates a scalability problem - there are many applications that cannot use it. On the other hand this can be a viable approach for lookup data.
What makes your case special is that you can spend the time loading all your DB into memory but you can't also wait untill you link all the objects (e.g. work in two passes load everyhing , then link everything)
Arnon
Ling Bao
Arnon, OzJester
Interestingly, in this scenario many of the classes have 1) slow changing data and 2) small numbers of objects. They therefore function like look-up data (as Arnon suggests) and it seems most efficient to get all the data (more than needed, but much of it can be cached for all users) once and then 'lazy-link' just those parts that are needed. As Arnon suggests the class-specific object cache(s) needs to be cleared after an update to the slow changing data.
There are therefore two reasons for not doing the linking as the objects are loaded. Firstly to link only those objects that need to be linked at that point in time and secondly to keep the 'Load object' methods as free as possible from procedural information (e.g. do this then that). I would have to agree that the space-saving gains may not be large. It also seems relative easy to refactor to loose the lazy link if at any point the decision needs to be reversed.
Thanks for all the comments, which are helping clarify all of the issues
Mike