On 5/30/07, Vincent Massol <vincent(a)massol.net> wrote:
On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote:
[snip]
Lazy types are not good, as they are storage
dependent. Hibernate has
this feature, but how about XML Database servers, or JCR? We'd
probably have to write our own storage-dependent wrappers.
On the other hand, I'd like *not* to have a storage dependency inside
the model classes. The model should only contain data.
The model should only contain data AND behaviors associated with this
data. For example I'm pretty confident we want to have
Space.getDocuments() for example in the model.
Of course. Data alone = storage.
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.
- 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.
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?
- We might
have to write the intermediate along with the storage, as
not all storage systems support lazy loading. This is not as bad as it
looks, because basically we're moving storage.load() from a model
class to a decorator class, and the decorator can be
storage-dependent.
Can we use JPOX (
http://www.jpox.org/ ) as the decorator for some
storage systems? Should we?
Yes we could. I know someone who's using it. I'll check with him.
[snip]
Thanks
-Vincent
Sergiu
--
http://purl.org/net/sergiu