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. If you do need to apply the DAO pattern with JCR, I suggest you take a look at the JCR Mapping tool in the Graffito project (http://incubator.apache.org/graffito/). It's an object-to-content mapping tool for JCR just like the various object-to-relational mapping tools for JDBC.
Second question, can I "butcher" jackrabbit in order to take out the core that handles the persistence stuff because I want to do all presentation stuff on my own (that is, is there a clean core module that I can integrate with my app)?
The Jackrabbit core (jackrabbit-core-1.1.jar) contains no presentation logic. It should fit your needs pretty well. BR, Jukka Zitting
