La biblioteca de clases con el apoyo de varias estrategias de persistencia

Question

Estoy desarrollando una clase de C++ biblioteca que contiene las clases de modelo de dominio, y me gustaría añadir soporte para crear instancias de estas clases de diversos mecanismos de persistencia, es decir,bases de datos y archivos.El usuario de la biblioteca de clase debe ser dado a una interfaz(?) contra la que se programa una clase que puede transferir los datos desde/a el mecanismo de persistencia.

Sé de los Objetos de Acceso a Datos patrón que parece funcionar para Java, pero no estoy exactamente seguro de cómo aplicarlo a la de C++.Hay otras soluciones?

Answer 1

C++ soporta la herencia múltiple, de modo que usted puede tener un genérico de la API de persistencia y heredar un mecanismo de persistencia.Esto sería todavía tiene que utilizar la introspección para salir de la clase de metadatos, pero usted todavía tiene este problema con cualquier capa de persistencia.

Alternativamente, usted podría hacer algo similar pero el uso de los metadatos para conducir un generador de código que se llena en el "Getters" y "Incubadoras" para la capa de persistencia.

Cualquier capa de persistencia se suelen utilizar uno u otro enfoque, por lo que su problema es de enganchar el mecanismo de carga en la capa de persistencia.Creo que esto hace que tu problema un poco diferente de la de una sola capa de persistencia sin embargo, abordar desde la otra dirección.En lugar de construir clases de dominio en un marco de persistencia de proporcionar un conjunto de clases de dominio con los ganchos para un marco de persistencia que terceros pueden conectar sus datos de acceso mecanismo.

Creo que una vez que usted proporciona acceso a los metadatos de clase y las devoluciones de llamada de la perisistence mecanismo es relativamente sencillo.Mira los metadatos de los componentes de cualquier conveniente C++ O/R mapping marco y entender cómo funcionan.Encapsular esta con una API en una de las clases base de sus clases de dominio y proporcionar un genérico de captador/definidor de la API para la creación de instancias o persistente.El resto es para la persona que la aplicación de la capa de persistencia.

Editar: No puedo pensar en una librería de C++ con el tipo de conectables mecanismo de persistencia que usted describe, pero hice algo en Python que podría haber tenido este tipo de instalaciones añadido.El particular, la aplicación utiliza las instalaciones en Python no directamente equivalente de C++, aunque el principio básico, probablemente, podría ser adaptado para trabajar con C++.

En Python, puede interceptar los accesos a las variables de instancia por razones imperiosas de __getattr()__ y __setattr()__.El mecanismo de persistencia en realidad mantuvo su propia caché de datos detrás de las escenas.Cuando la funcionalidad se mezclan en la clase (de hecho a través de la herencia múltiple), se anuló el sistema predeterminado de comportamiento para los miembros de acceder y comprobar si el atributo que se está consultando igualado nada en su diccionario.Cuando esto sucedió, la llamada se redirige a obtener o establecer un elemento en la caché de datos.

La caché tenía metadatos de su propio.Era consciente de que las relaciones entre entidades dentro de su modelo de datos, y sabía que los nombres de atributo para interceptar el acceso a los datos.La manera en que esto trabajaba separados de la base de datos de la capa de acceso y podría (al menos en teoría) han permitido que el mecanismo de persistencia para ser utilizado con diferentes conductores.No hay ninguna razón intrínseca que no podía tener (por ejemplo) construyó un conductor que serializado a un archivo XML.

Hacer algo como esta el trabajo en C++ sería un poco más complicado, y puede no ser posible hacer que el objeto de acceso a la caché transparente como fue con este sistema.Probablemente sería mejor con una explícita protocolo que se carga y descarga el estado del objeto en la caché.El código para esto sería muy susceptibles a la generación de la caché de metadatos, pero esto tiene que ser hecho en tiempo de compilación.Usted puede ser capaz de hacer algo con plantillas o reemplazando el -> operador para realizar el protocolo de acceso más transparente, pero esto es probablemente más problemas de lo que vale.

Answer 2

Impulsar La Serialización proporciona algunos bastante cosas útiles para trabajar con serializar los tipos C++, pero de lo bien que va a coincidir con la interfaz que deseo no lo sé.Es compatible tanto con el intrusivo y no intrusiva de los diseños, así que es bastante flexible.

Answer 3

Me gustaría evitar la serialización, en mi humilde opinión, la implementación de esta para una de nuestras aplicaciones de MFC en el año 1995, hemos sido lo suficientemente inteligente como para utilizar los objetos independientes de control de versiones y control de versiones de archivos, pero que terminan con un montón de viejos código desordenado alrededor de después de la hora.

Imaginar escenarios, dejar de clases, dejar de miembros, etc, cada uno de ellos presenta un nuevo problema.Ahora vamos a utilizar compreseds "de tipo XML" arroyos, podemos añadir nuevos datos y mantener la compatibilidad hacia atrás.

La lectura y la escritura el archivo es un resumen de la asignación de los datos a los objetos, ahora podemos cambiar los formatos de archivo, agregar los importadores/exportadores sin modificación a nuestro core business objects.

Dicho esto, algunos desarrolladores amor de serialización, mis propios encuentros es que el código de cambio de base, plataformas, lenguajes, herramientas todas traen consigo una gran cantidad de problemas, lectura y escritura de los datos no debe ser uno de ellos.

Además el uso de un formato de datos estándar, con algunas marcas clave, significa mucho más fácil trabajar con 3ras partes.

Answer 4

Usted puede buscar en impulsar la serialización.De no haber utilizado que no sé si recomendarlo o no.Impulsar las bibliotecas son generalmente de alta calidad.