¿Quiero un ORM?

Question

Tenemos un modelo de objeto que se utiliza en tres aplicaciones. Dos programas recopilan datos, otros lo leen y generan informes. El sistema está muy desconectado, por lo que no podemos tener una sola base de datos con la que todos los programas hablen.

En este momento, los programas solo usan una biblioteca común para rellenar un modelo de objetos y serializar/deserializar en el disco. Específicamente, estamos usando la serialización XML.

Hay un par de problemas con este modelo. 1) XML podría considerarse un desperdicio. Los archivos pueden ser grandes y difíciles de manejar. Honestamente, el tamaño del archivo no es una gran preocupación en este momento. 2) Mi mayor preocupación es la huella de memoria. El archivo completo se carga en un modelo de objetos, se opera y luego se guarda.

Espero haber transmitido mi preocupación, en algún momento nos encontraremos con problemas de memoria con esta aplicación durante el tiempo de ejecución. Se recopilarán suficientes datos en una sola "base de datos" (archivo xml) que no se pueden cargar en la memoria de una sola vez.

Lo que me gustaría tener, es el acceso a mi modelo de objetos respaldado por el almacenamiento de archivos en lugar de la memoria. Quiero que los cambios en el modelo de objetos sean mínimos. Cuando se accede a un objeto, proviene del disco y, cuando está configurado, se guarda (automáticamente, si es posible).

Hemos examinado NHibernate con SQLite, SQL Compact 4.0 y EF 4, y LINQ to XML (brevemente). También he usado db4o en el pasado para almacenar en caché los objetos en el disco, pero ese era un proyecto no relacionado.

Antes de bucear y dedicar tiempo a aprender uno de estos, me gustaría saber si mi idea tiene sentido. ¿Puedo tener un modelo de objetos que caché "mágicamente" en un medio de almacenamiento en lugar de simplemente hinchar la huella de mi memoria infinitamente? ¿Cuál es el camino más corto para hacer esto, incluso si no es el más elegante?

¿Hay otras tecnologías que podrían ayudarme? Archivos mapeados en memoria, linq-to-sql, Lazy (T) (solo para recuperar objetos de archivos cuando sea necesario).

Me doy cuenta de que esta es una pregunta abierta. Estoy buscando una respuesta de imagen completa y detalles si alguien tiene experiencia en el mundo real al hacer esto. Los enlaces serían útiles ...

Gracias.

Answer 1

Acabo de terminar de migrar una aplicación web (en su mayoría "heredada") respaldada por archivos XML a NHibernate exactamente fuera de las mismas preocupaciones. También estaba en la misma situación de nunca haber usado NHibernate antes y querer aprender en el proceso. La idea tiene sentido. De hecho, podrá cargar en la memoria solo las partes que realmente necesita (a diferencia de toda la base de datos) y muchos más beneficios que eso.

Según las otras cosas que pida (cambios mínimos en el modelo de objeto, fácil de migrar de aplicaciones reales a basadas en ORM) No estoy seguro de que las obtenga tan fácilmente. Con ORM como NHibernate y EF4, las clases de modelo son muy livianas: básicamente son poco más que contenedores de propiedades. Las aplicaciones basadas en archivos XML tienden a tener más lógica directamente en el modelo: esa lógica probablemente tendrá que pasar a la capa de acceso a datos. El rediseño del modelo y la capa de acceso a los datos probablemente sea la tarea que consuma más tiempo. Sé que fue para mí.

Otra cosa que deduzco de su pregunta (usted dice que no puede tener los tres programas hablando con la misma base de datos y menciona SQLite y SQL Compact) es que está replicando sus datos entre sus tres aplicaciones copiando el archivo físicamente ¿Cómo se detectan los cambios y qué tan alineados se necesitan los 3 DB? ¿Cómo fusiona actualmente los cambios (en el caso 2 de las 3 aplicaciones que tiene puede escribir datos)? Dependiendo de cómo replique los datos, esto es algo con lo que un ORM puede o no puede ayudarlo.

Editar algunos puntos más en base a sus comentarios

• Si desea en un punto para combinar los archivos en una base de datos y aún no se encuentra seguro de que será un producto de Microsoft, entonces es NHibernate La mejor decision. Pero si ahora estás usando LINQ extensivamente (según otro de tus comentarios) y quieres una transición más fluida, yo elegiría EF4: Nhibernate.Linq no está realmente completo y algunas construcciones no funcionan.
• Tanto NHibernate como EF4 están muy documentados y vienen con muy buenos tutoriales sobre cómo crear una aplicación completa desde cero, por lo que la parte de aprendizaje es realmente fácil.
• Ambos tienen un enfoque de "modelo primero" donde obtiene una herramienta que crea su base de datos para usted en función de sus clases de modelo, por lo que si sus clases de modelo son muy livianas debería poder usarlas con pequeñas modificaciones.
• lo que me llevó algún tiempo (y todavía me cuesta trabajar) en NHibernate está configurando las cascadas para que se comporten de la manera que esperaba: p. ¿Qué sucede con los objetos "relacionados" cuando elimina un objeto?

Answer 2

Sí, el mapa de ORM es un modelo de objeto para un modelo relacional. Hacen un buen trabajo al ocultar todo el trabajo de fontanería relacionado con la lectura y escritura de datos en la base de datos, almacenamiento en caché de datos, administración de memoria, etc. También son muy capaces de almacenar en caché partes de un gráfico de objetos y pueden hacer cosas para mejorar el rendimiento como datos de carga perezosos.

Answer 3

Mi sugerencia es que utilice una base de datos de documentos. RavenDB le daría muchos beneficios. Sería capaz de almacenar los objetos sin convertirlos en un modelo relacional, muy parecido a como lo haría db4o.

Sin embargo, con RavenDB tiene una gran posibilidad de consultar los datos usando Map/Reduce. Otro beneficio es que está escrito usando .NET para .NET, por lo que disfrutará de consultas en Linq. Se puede ejecutar como un servicio de Windows o en IIS. También se puede ejecutar incrustado, lo cual es ideal para fines de prueba. Puede ser una buena idea para sus aplicaciones de recolección de datos.

RavenDB también es compatible con la replicación, por lo que puede almacenar datos en una instancia y replicarlos en otra. Tal vez eso podría resolver la configuración distribuida que tienes.

Sin embargo, dependiendo de la naturaleza de su configuración distribuida, creo que sería mejor usar un bus de servicio. ¿Necesita estado en las aplicaciones de recopilación de datos? Si no, simplemente publique un mensaje que contenga los datos en el bus de servicio para que consuma otra parte del sistema. Puede sonar complejo, pero en realidad no lo es. Eche un vistazo al nServicebus.