30 May
2007
30 May
'07
12:08 p.m.
On May 30, 2007, at 11:54 AM, Sergiu Dumitriu wrote:
[snip]
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).
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).
I don't understand what "domain objects" are. Can you explain?
I meant model classes.
[snip]
Thanks
-Vincent
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?
- 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.
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.