[xwiki-dev] Re: [ArchitectureV2] Model proposal

[Sergiu Dumitriu]

On 5/30/07, Vincent Massol <vincent at 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