hi maarten, thanks for your question.
> I'm new to the JCR philosophy and also a little bit confused on how > we should this new technology in an N-Tier architecture. I'm used > on working with Hibernate, pojo's and ORM mappings in this kind > of environment and have the following questions about JCR > implementations: > Let's take for example a simple blogging website (that's seems to be > the "hello world" example for JCR :) ... ) hehe ;) > - Is JCR only present behind the DAO layer or do the nodes and > so traverse through all layers i think that this is subject to the "implementation style" and the "application". personally, i like a mix of pojo and direct access to the nodes and properties. sometimes it is very convenient to be able to just access the nodes and properties directly from your presentation-layer for very simple things (mostly generic display). if there is only a hint of "business logic" involved, i usually appreciate a pojo instead. once you have the pojo there is not much reason to go back to the nodes and properties directly. > - If the JCR in not shielded behind pojo's and the DAO, I find it difficult > to understand how we should expose JCR retrieved data? Should we > use the JCR api also in the presentation layer ... i hope not!!! well, it is up to the application how much you want to shield. let's say an application like http://jsr170tools.day.com/crx/browser/index.jsp does not experience any benefit of wrapping the nodes and properties. also, in my experience a lot of the just "template presentation logic" does not really benefit from that either. > - If the JCR is indeed behind the DAO ... how do we go on from the DAO > to the presentation layer? Do we still use pojo, for example with a pojo > called BlogMessage which have references to its parent and > child BlogMessages? If so what is the best practise to create and > update data that is changed in these pojo's. I'm a little bit lost with the > use of pojo's in combination with JCR!!! yes, a pojo is the right way of doing that. i think at this point there is still a bit of hand coding involved in the creating the the java classes from the nodetypes or vice-versa. updates can be subscribed to through observation. personally, i would love to have a robust, annotations-based "object-content-mapping" (ocm) framework. on the bright side of things a "content repository" (opposed to an rdbms) can actually deal with inheritance (and even aspects) in a native fashion and therefore architecturally lends itself much better for pojo persistence. > - What about transactions ... is that possible with JCR yes. > - If the JCR impl is backed by i.e. Hibernate ... how > will the JCR data will be saved. Is there still a ORM mapping > behind the scenes or how is this done? i never saw much value in backing a content repository by an orm-layer. i am a bit more of a fan of a relatively direct jdbc backing, since i think that there is no real value at a low level like the persistence manager to introduce additional abstraction. i am sure other people feel differently. ;) > So, it would be great that someone explains a real life example on > how to use JCR in an N-Tier architecture... i think you may find some more info in graffito. (right, christophe?) http://incubator.apache.org/graffito/ as i said i am convinced that a content repository is an ideal store to persist pojo's and i think that it is a matter of time until robust generic mapping frameworks are available. regards, david
