When possible I typically try to avoid extra layers on top of JCR.
Unlike relational databases, JCR is actually quite "OO-friendly" so
the need for an DAO/DTO layer is not that big. Typically such a layer
just ends up limiting the available functionality.
I'm not against the OCM tool as is, I think it is very useful when you
already have an existing object model to be persisted, but if you get
to start from scratch then I would rather recommend directly using
JCR.
Personally, I think JCR is an excellent choice for the persistence layer
but not in the business services and presentation layer.
Building business logic with "business" objects is less verbose and more
easy to maintain. Furthermore, it is always interesting to make abstraction
on the technology to use in the persistent layer. A lot of web design
patterns used for DB web app can be used also for JCR web app.
My favourite way of working with JCR is to treat nodes as stateful
resources, and my code as a set of stateless operations to be applied
on those resources. Such an approach is very "web-friendly".
When a remote JCR server is used, what about a JCR session pool (in each web
apps accessing the JCR server) and a complete stateless situation ? I would
like to test this kind of situation with Jackrabbit.
