biblioteca de classe com suporte para várias estratégias de persistência

Question

Estou desenvolvendo uma biblioteca de classes C ++ que contém classes de modelo de domínio, e eu gostaria de adicionar suporte para instanciar essas classes a partir de vários mecanismos de persistência, bancos de dados ou seja, e de arquivo. O usuário da biblioteca de classes deve ser dada uma interface (?) Na qual programar uma classe que pode transferir os dados de / para o mecanismo de persistência.

Eu sei do padrão Data Access Object que parece trabalho para Java, mas eu não sei exatamente como aplicá-la para C ++. Existem outras soluções?

Answer 1

suportes C ++ herança múltipla, assim você pode ter um API persistência genérico e herdar um mecanismo de persistência. Isso ainda teria que usar introspecção para sair os metadados de classe, mas você ainda tem esse problema com qualquer camada de persistência.

Como alternativa, você poderia fazer algo semelhante, mas usar os metadados para dirigir um gerador de código que preenche o 'Getters' e 'setter' para a camada de persistência.

Qualquer camada de persistência usará tipicamente um ou outro método, para que o seu problema é ligar o mecanismo de carregamento para a camada de persistência. Eu acho que isso faz com que seu pouco diferente problema a partir de uma camada de persistência única, mas enfrentá-lo de outra direção. Ao invés de construir classes de domínio para um framework de persistência você está fornecendo um conjunto de classes de domínio com os ganchos para um framework de persistência que terceiros pode conectar seu mecanismo de acesso a dados em.

Eu acho que uma vez que você fornecer acesso aos metadados e retornos de chamada classe do mecanismo perisistence é relativamente simples. Olhe para os componentes de metadados de qualquer C ++ conveniente framework de mapeamento O / R e entender como eles funcionam. Encapsular isso com uma API em uma das classes base de suas classes de domínio e fornecer um genérico API getter / setter para instanciação ou persistentes. O resto é com a pessoa implementação da camada de persistência.

Editar: Não consigo pensar em uma biblioteca C ++ com o tipo de mecanismo de persistência pluggable que você está descrevendo, mas eu fiz algo em Python que poderia ter tido este tipo de facilidade adicional. A implementação específica instalações em Python usado sem C ++ direta equivalente, embora o princípio básico provavelmente poderia ser adaptado para trabalhar com C ++.

Em Python, você pode interceptar acessos a variáveis ??de instância, substituindo __getattr()__ e __setattr()__. O mecanismo de persistência realmente mantido a sua própria cache de dados nos bastidores. Quando a funcionalidade foi misturado na classe (feito através de herança múltipla), que anulou o comportamento do sistema padrão para acessar membro e verificado se o ser atributo consultado nada combinava em seu dicionário. Onde isso aconteceu, a chamada foi redirecionada para obter ou definir um item no cache de dados.

O cache teve metadados própria. Ele estava ciente de relações entre entidades dentro do seu modelo de dados, e sabia nomes que atributo para interceptar os dados de acesso. A forma como isto trabalhou separava a camada de acesso a base de dados e pode (pelo menos em teoria) têm permitido o mecanismo de persistência para ser utilizada com condutores diferentes. Não há nenhuma razão inerente que você não poderia ter (por exemplo) construiu um driver que serializada-lo para um arquivo XML.

Fazer algo como este trabalho em C ++ seria um pouco mais complicadas, e pode não ser possível fazer o acesso ao cache de objeto como transparente como foi com este sistema. Você provavelmente seria melhor com um protocolo explícito que carrega e descarrega o estado do objeto para o cache. O código para isso seria bastante passíveis de geração a partir dos metadados cache, mas isso teria que ser feito em tempo de compilação. Você pode ser capaz de fazer algo com modelos ou substituindo o operador -> para fazer o protocolo de acesso mais transparente, mas isso é provavelmente mais problemas do que vale a pena.

Answer 2

impulsionar serialização fornece algumas bastante material útil para trabalhar com a serialização de tipos C ++, mas o quão bem ele irá coincidir com a interface que você deseja Eu não sei. Ele suporta ambos os projetos invasivos e não invasivos, assim é bastante flexível.

Answer 3

Gostaria de evitar a serialização, IMHO, implementamos este para uma das nossas aplicações em MFC em 1995, estávamos bastante inteligente para usar objeto independente de versão, eo arquivo de versão, mas você acaba com um monte de código messy volta após o tempo.

Imagine que determinados cenários, depreciativo aulas, depreciativo membros, etc, cada um apresenta um novo problema. Agora usamos compreseds streams "tipo XML", podemos adicionar novos dados e manter a compatibilidade com versões anteriores.

Ler e escrever o arquivo é captada a partir mapear os dados para os objetos, agora podemos mudar formatos de arquivo, adicione importadores / exportadores, sem modificação para nossos objetos de negócio.

Dito alguns desenvolvedores amo serialização, meus próprios encontros é que a mudança de base de código, plataformas, linguagens, ferramentas todos trazer um monte de problemas, ler e escrever seus dados não deve ser um deles.

Além disso usando um formato de dados padrão, com algumas chaves patenteado, significa que a sua muito mais fácil de trabalhar com 3 partes.

Answer 4

Você pode gostar de olhar para impulso serialização . Não ter usado isso Eu não posso dizer se a recomendá-lo ou não. bibliotecas de impulso são normalmente de alta qualidade.