Jukka Zitting wrote:
Hi,
On 10/24/06, Srepfler Srgjan <[EMAIL PROTECTED]> wrote:
I have implemented the DAO pattern so I can switch between
persistence layers but to me it seems the two approaches are mutually
exclusive. Can someone give me advice what's the best way to combine
these two technologies and how to get the most of both worlds?
I generally prefer to expose the JCR Node/Property model all the way
up to the business and presentation logic. The way I see it, the DAO
pattern solves two different problems: it allows you to swap
persistence mechanisms and it hides the underlying data access API
behind a more natural OO API. The latter issue mostly affects cases
maps poorly to implementing common business or presentation logic
(JDBC). I find the JCR API quite natural to work with (compare
Node.getProperty(...) with the JDBC equivalent of executing a SELECT,
possibly caching the results over multiple calls, etc.) so from my
perspective the main reason for using the DAO pattern over JCR is when
you either need to use a persistence mechanism that doesn't support
JCR or to transparently support different JCR content models.
While I can see that using a JCR api is superior to JDBC I somehow
prefer the Annotations-oriented POJO approach that is used by the
JPA/EJB3. I've focused on building a reasonable model and thinking in
terms of Nodes/Properties and trying to fit everything in that model
seems a bit unintuitive and frankly anti-OO.
I feel that if the framework would be able to understand the annotations
on the entities and map them to Node/Properties in a transparent way (if
possible) that would be the most intuitive approach. Is such a thing
possible, is it worth it, are there alternative approaches (ex.
extending the set of annotations)?
Thanks, Srgjan
