Question

Je développe une bibliothèque de classes C ++ contenant des classes de modèle de domaine et j'aimerais ajouter un support pour instancier ces classes à partir de divers mécanismes de persistance, tels que les bases de données et les fichiers. L’utilisateur de la bibliothèque de classes doit avoir une interface (?) Contre laquelle programmer une classe pouvant transférer les données de / vers le mécanisme de persistance.

Je connais le modèle d'objet d'accès aux données qui semble fonctionner pour Java, mais je ne sais pas exactement comment l'appliquer à C ++. Y a-t-il d'autres solutions?

Était-ce utile?

La solution

C ++ prend en charge l'héritage multiple afin que vous puissiez disposer d'une API de persistance générique et hériter d'un mécanisme de persistance. Il faudrait toujours utiliser l'introspection pour extraire les métadonnées de classe, mais vous auriez toujours ce problème avec n'importe quel calque de persistance.

Vous pouvez également faire quelque chose de similaire, mais utiliser les métadonnées pour piloter un générateur de code qui remplit les champs "Getters" et "Setters" de la couche de persistance.

Toute couche de persistance utilise généralement l’une ou l’autre approche. Votre problème est donc d’attacher le mécanisme de chargement à la couche de persistance. Je pense que cela rend votre problème un peu différent d’une couche de persistance unique, mais en l’attaquant dans une autre direction. Plutôt que de créer des classes de domaine sur un framework de persistance, vous fournissez un ensemble de classes de domaine avec les points d'ancrage d'un framework de persistance auquel des tiers peuvent connecter leur mécanisme d'accès aux données.

Je pense qu’une fois que vous avez fourni l’accès aux métadonnées de classe et aux rappels, le mécanisme de périsistence est relativement simple. Examinez les composants de métadonnées de tout framework de mappage C ++ O / R pratique et comprenez leur fonctionnement. Encapsulez ceci avec une API dans l'une des classes de base de vos classes de domaine et fournissez une API générique getter / setter pour l'instanciation ou la persistance. Le reste appartient à la personne qui implémente la couche de persistance.

Modifier: Je ne vois pas de bibliothèque C ++ avec le type de mécanisme de persistance enfichable que vous décrivez, mais j'ai déjà fait quelque chose en Python qui aurait pu ajouter ce type d'installation. L’implémentation particulière utilisait des fonctionnalités en Python sans équivalent direct en C ++, bien que le principe de base puisse probablement être adapté pour fonctionner avec C ++.

En Python, vous pouvez intercepter les accès à des variables d'instance en remplaçant __ getattr () __ et __ setattr () __ . Le mécanisme de persistance conservait en réalité son propre cache de données en arrière-plan. Lorsque la fonctionnalité était mélangée à la classe (via l'héritage multiple), le comportement par défaut du système pour les membres accédant était annulé, et il était vérifié si l'attribut interrogé correspondait à quoi que ce soit dans son dictionnaire. Dans ce cas, l’appel a été redirigé pour obtenir ou définir un élément dans le cache de données.

Le cache avait ses propres métadonnées. Il était conscient des relations entre les entités au sein de son modèle de données et savait quels noms d'attribut devaient être interceptés pour accéder aux données. La façon dont cela fonctionnait le séparait de la couche d'accès à la base de données et aurait pu (du moins en théorie) permettre au mécanisme de persistance d'être utilisé avec différents pilotes. Par exemple, il n’existe aucune raison pour laquelle vous n’auriez pas pu (par exemple) créer un pilote qui l’a sérialisé dans un fichier XML.

Faire en sorte que quelque chose comme cela fonctionne en C ++ serait un peu plus complexe, et il ne sera peut-être pas possible de rendre l'accès au cache des objets aussi transparent qu'avec ce système. Vous feriez probablement mieux avec un protocole explicite qui charge et vide l'état de l'objet dans le cache. Le code correspondant serait assez facile à générer à partir des métadonnées de cache, mais cela devrait être fait au moment de la compilation. Vous pourrez peut-être faire quelque chose avec des modèles ou en surchargeant l'opérateur - > pour rendre le protocole d'accès plus transparent, mais cela représente probablement plus de problèmes que cela ne vaut la peine.

Autres conseils

Renforcer la sérialisation fournit de jolis outils trucs utiles pour travailler avec des types C ++ en sérialisation, mais je ne sais pas à quel point cela correspond à l'interface que vous désirez. Il prend en charge les conceptions intrusives et non intrusives, il est donc assez flexible.

J'évitais la sérialisation, à mon humble avis, nous l'avions mise en œuvre pour l'une de nos applications dans MFC en 1995. Nous étions suffisamment intelligents pour utiliser le contrôle de version des objets et le contrôle de version des fichiers, mais vous vous retrouvez avec beaucoup de vieux codes désordonnés. après le temps.

Imaginez certains scénarios, déprécier des classes, déprécier des membres, etc., chacun présentant un nouveau problème. Nous utilisons maintenant le type "& XML; Compreseds" flux, nous pouvons ajouter de nouvelles données et maintenir une compatibilité ascendante.

La lecture et l’écriture du fichier sont résumées par le mappage des données sur les objets. Nous pouvons maintenant changer de format de fichier, ajouter des importateurs / exportateurs sans modifier nos objets de base.

Cela étant dit, certains développeurs adorent la sérialisation. Mes propres rencontres sont les suivantes: changer de base de code, de plates-formes, de langages et de boîtes à outils pose de nombreux problèmes, lire et écrire vos données ne devrait pas en faire partie.

De plus, l’utilisation d’un format de données standard, avec une clé propriétaire, simplifie grandement le travail avec des tiers.

Vous pouvez consulter la sérialisation accélérée . Ne l'ayant pas utilisé, je ne saurais le recommander ou non. Les bibliothèques Boost sont généralement de haute qualité.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top