Collections, providers de données et persistance

Statut documentaire : guide. Les API précises des providers dépendent du module et de la version du Runtime.

Séparer déclaration et provider exécutable

Le modèle déclaratif décrit une classe et ses collections. À l'exécution, les métadonnées ClassItem activées résolvent un collection provider adapté à la déclaration et à la configuration. Le provider est la frontière exécutable de requête/d'accès aux données, utilisée par datasets, services et projections. Un ObjectItem est un objet métier Runtime ; il ne se réduit pas à une ligne SQL.

Parcours courant

1. Définir collection et identité métier au niveau MODEL.
2. Charger les packages et assembler les métadonnées APPLICATION.
3. Résoudre le provider de collection depuis la classe Runtime activée.
4. Préciser attentes de requête, filtre, pagination, identité objet, transaction et posting.
5. Projeter le résultat vers datasets, endpoints de services ou données sérialisées.
6. Tester lecture/écriture indépendamment du transport et de la vue.

Providers SQL, brokers, adaptateurs de collections et sérialiseurs couvrent des responsabilités distinctes. Le choix d'une base ne doit pas redéfinir silencieusement le contrat conceptuel. Sérialisation modèle/graphe et persistance base peuvent aussi suivre des règles différentes d'identité et de version.

Valider la frontière

Tester résultats vides, pagination, tri, échecs partiels, frontières transactionnelles, préservation d'identité et écritures concurrentes. Diagnostiquer si un écart relève du modèle, du provider, du mapping, du sérialiseur ou de la présentation avant de changer la sémantique.

Suite

Collections, vues et datasets · Persistance et cohérence · Plan des données · Déploiement SQL/providers

Sources LaTeX : datastructures-and-brokers.tex ; collection-providers.tex ; sql-data-engine.tex ; serialization-and-deserialization.tex.