On May 30, 2007, at 11:54 AM, Sergiu Dumitriu wrote: [snip]
Pros and cons of lazy loading data: Pros - We can reduce the amount of time/memory needed to load a document
Well this is the same as with the other option I believe as for example we would retrieve documents only when Space.getDocuments() get called the first time. Or do you mean something else?
Not quite. Space.getDocuments can do: 1. load from the storage all the documents in that space 2. load a lazy list that reflects the number of documents in the database. When we try to access an entry in the database, we load that document, and only that document.
Ok I agree but this can be done with either solutions. So I think we agree we want to have the Space.getDocuments() methods in the model classes and calling them will return database data (either when they are called or when the relationship is navigated).
- There's no dependency on the storage inside the model
There's a dependency but it's a runtime dependency rather than a source time dependency.
The dependency is hidden inside the decorator, and isn't visible in the model classes. So yes, it's a runtime dependency.
One drawback is that you need to tell somewhere where you want the interceptor to plug into. This can be done with a configuration file (I don't know how jpox does it) or it can be done using some annotation. In that case we come back to a source dependency but it has the advantage of being more maintainable (otherwise you need to ensure you config file and your class/methode names are always in sync).
Cons - We need an intermediate between storage and model (decorator?)
Yes, this requires some magic (byte code enhancement) if you want to make it transparent. Otherwise you need an API to load data and then only you're allowed to use the domain objects, which isn't nice.
I don't understand what "domain objects" are. Can you explain?
I meant model classes. [snip] Thanks -Vincent