Nice Discussion ! After making different projects based on Jackrabbit & OCM, my opinion is changing (don't blame me, I'm one of the committer of the Jackrabbit OCM !). I came from the ORM technologies for building applications with many layers. The more layers we had, the better it was. But now, my opinion is changing because we are building content applications in a different way . Indeed, there are new concepts & new technologies that can help us to have a simpler architecture (aka OSGI, REST & JCR or "Sling ;-)"). With all of that, OCM is not mandatory. I know, it is a long debate but I'm very surprising on how we have simplified the code for a customer application, just by using Sling (without speaking about the dev time). Read more on [1].
Concerning OCM, I'm changing my opinion because (in a random order) : - JCR code on server side is very fast. Adding more layers & mapping will decrease the performance and add complexity in the architecture. - The server codes are generally smalls. So, using the JCR API is not a problem (even if JCR code is more verbose). - JCR is a standard, OCM is not. OCM has to reimplement all JCR features in another/non standard API. - JCR spec is simple to learn for a developer (no annotations, no mapping). The model is simple : Items, Nodes, Properties for everything. JCR code can be more generic. - Changing the content model is easier with JCR than with OCM. Difficulties to follow : "data first, structure later" with OCM. Again, don't blame me but I think OCM was not a good idea. Make a try with Sling and you will see how the JCR code can be simple. [1] Just for the fun : http://www.slideshare.net/lars3loff/the-zero-bullshit-architecture (sorry for the "free marketing" but it is so true) 2009/11/17 Janne Jalkanen <[email protected]> > > On 17 Nov 2009, at 14:50, Sandro Boehme wrote: > > > Alexander Klimetschek schrieb: > >> 2009/11/16 Fabián Mandelbaum <[email protected]>: > >>> It's simpler than fiddling around with this low-level stuff actually: > >>> > >>> Just create a DAO to abstract all JCR operations (as you should be > >>> doing already) > >> (To give my usual opinion about object content mapping and JCR:) If > >> you use DAOs this of course is a straight-forward solution (but only > >> for the code that uses the DAO layer), but I think that using JCR > >> directly is not "low-level" stuff: > > In my opinion an OCM adds statical type checking and the ability to add > functionality (e.g. finder methods) to this types. > > JSPWiki uses a layer on top of JCR to > a) provide type/range checking for some values, and > b) to provide backwards API compatibility. > > /Janne >
