¿Cuál es la mejor manera de guardar mis POJOs en Jackrabbit JCR?

Question

En Jackrabbit he experimentado dos formas de ahorrar mis POJOs en nodos de repositorio para el almacenamiento en el Jackrabbit JCR:

1. escribir mi propia capa y
2. usando Apache pintada

escribir mi propia el código ha demostrado ser lento y requiere mucha mano de obra (tuvo que escribir y ejecutar muchas pruebas automáticas desagradables) aunque fue bastante flexible.

Uso de la pintada ha sido una decepción, ya que parece ser un "muerto" proyecto stuck in 2006

¿Cuáles son algunas alternativas mejores?

Answer 1

Otra alternativa es omitir por completo un marco de OCM y simplemente usar javax.jcr.Node como un DAO muy flexible. La razón fundamental por la que existen los marcos OCM es porque con RDBMS necesita una asignación de objetos al modelo relacional. Con JCR, que ya está muy orientado a objetos (nodo ~ = objeto), esta razón subyacente se ha ido. Lo que queda es que con los DAO puedes restringir a lo que tus programadores pueden acceder en su código (incluida la ayuda de autocompletar). Pero este enfoque no aprovecha realmente el concepto de JCR, lo que significa programación flexible y sin esquema. Usar la API de JCR directamente en su código es la mejor manera de seguir ese concepto.

Imagine que desea agregar una nueva propiedad a un nodo/objeto existente más adelante en la vida de su aplicación, con un marco OCM también debe modificarlo y asegurarse de que todavía funciona correctamente. Con acceso directo a los nodos, es simplemente un único punto de cambio. Lo sé, esta es una buena manera de obtener problemas con los errores tipográficos, por ejemplo. nombres de propiedad; pero este temor en realidad no está respaldado por la realidad, ya que en la mayoría de los casos notarás muy rápidamente los errores de ortografía o los nombres que no coinciden cuando pruebas tu aplicación. Una buena solución es usar constantes de cadena para los nombres comunes de nodo o propiedad, incluso como parte de sus API si expone la API JCR a través de ellas. Esto todavía le da la flexibilidad de agregar rápidamente nuevas propiedades sin tener que adoptar capas OCM.

Para tener algunas limitaciones sobre lo que está permitido o lo que es obligatorio (es decir, "semi-schema") puede usar tipos de nodos y mixins (desde JCR 2.0 también puede cambiar el tipo de nodo para el contenido existente): puede manejar esto completamente en el nivel de repositorio y no tiene que preocuparse por tipeo y restricciones dentro del código de su aplicación, además de capturar las excepciones ;-)

Pero, por supuesto, esta elección depende de sus requisitos y preferencias personales .

Answer 2

Es posible que desee echar un vistazo a Jackrabbit OCM que está vivo y pateando. Por supuesto, otra forma es serializar/deserializar manualmente los POJO. Para eso hay muchas opciones diferentes. La pregunta es si necesita un esquema de arreglos para consultar los objetos en JCR. Si solo desea serializar en XML, entonces XStream es una forma muy sencilla de hacerlo. Si necesita un esquema de corrección adicional, también existe Betwixt de Apache Commons.

Answer 3

También está el proyecto JCROM en http://code.google.com/p/jcrom/. Ese proyecto quedó inactivo durante un par de años, pero ha habido algunos lanzamientos nuevos a partir del verano de 2013.

Answer 4

Depende de sus necesidades. Cuando usa directamente javax.jcr.node, significa que su código está fuertemente acoplado al mecanismo subyacente. En proyectos medianos e incluso pequeños, esta no es una buena idea.Obviamente, la pregunta será cómo pasar del Nodo a su propio modelo de dominio. El problema es bastante similar al pasar de Jdbc ResultSet a su propio modelo de dominio. Eso sí, quiero decir, desde el punto de vista técnico, que el problema es similar. Desde un punto de vista funcional, existen enormes diferencias entre el uso de JDBC y JCR.

Otro factor decisivo es si puede imponer una estructura en su contenido JCR o no. Algunos dominios de aplicación pueden (pero aún combinan mejor con JCR que JDBC), en otros dominios el contenido puede ser de naturaleza altamente desestructurada. En tal caso, OCM es claramente excesivo. Aún así, me gustaría escribir tu propia capa de envoltura alrededor de las clases javax.jcr. *.

Answer 5

También hay https://github.com/ilikeorangutans/omf, un objeto muy flexible para el mapeador JCR. Lamentablemente, todavía no tiene soporte de escritura. Sin embargo, estamos utilizando con éxito este marco en una gran instalación de CMS.