Patrons de conception/Gestion de données
Les objets et les bases de données relationnelles ont des mécanismes différents pour structurer les données.
De nombreuses parties d'un objet, telles que les collections et l'héritage, ne sont pas présentes dans les bases de données relationnelles.
Lorsque vous créez un modèle d'objet avec beaucoup de logique métier, il est utile d'utiliser ces mécanismes pour mieux organiser les données et le comportement qui les accompagne.
Cela conduit à des variantes de schémas ; c'est-à-dire que le schéma d'objet et le schéma relationnel ne correspondent pas.
| Patron de conception | |
|---|---|
| Catégorie : Entreprise – Architecture de source de données | |
| Nom français : | Gestion de données |
| Nom anglais : | Data Mapper |
| Une couche de gestion qui transfère des données entre les objets et la base de données tout en les gardant indépendants entre eux et le gestionnaire lui-même. | |
Vous devez toujours transférer des données entre les deux schémas, et ce transfert de données devient une complexité en soi. Si les objets en mémoire connaissent la structure de la base de données relationnelle, les modifications apportées à l'un ont tendance à se répercuter sur l'autre.
Le gestionnaire de données est une couche logicielle qui sépare les objets en mémoire de la base de données. Sa responsabilité est de transférer les données entre les deux et aussi de les isoler l'un de l'autre. Avec un gestionnaire de données, les objets en mémoire n'ont même pas besoin de savoir qu'une base de données est présente ; ils n'ont besoin d'aucun code d'interface SQL et certainement d'aucune connaissance du schéma de la base de données (Le schéma de base de données ignore toujours les objets qui l'utilisent). Puisqu'il s'agit d'une forme de Mapper, le gestionnaire de données lui-même est même inconnu de la couche métier.