Cache de données de vue

Statut documentaire : guide — voir Maturité et preuves.

Une vue doit se lier à une surface de données de page plutôt que directement à une base, un service, un provider ou une collection métier brute. Le cache de données de vue fournit cette surface stable.

Les trois surfaces de données

• DataSet : quelles données sont visibles dans ce contexte de vue ? Il peut représenter des enregistrements, objets, sous-ensembles filtrés, résultats de requête ou projections calculées.
• DataSource : quelle surface de binding stable consomme un composant ?
• DataCursor : quel est l’objet courant ou la position courante ? Il transporte le contexte des vues master-detail et imbriquées.

Ensemble, ils forment la mémoire de données locale de la page.

Chemin des données

composant fonctionnel
 -> DataSource
 -> DataSet
 -> Collection conceptuelle
 -> Provider
 -> mémoire locale / persistance / service / flux / source distante

Le composant ne doit pas connaître le provider réel. La même vue peut ainsi fonctionner avec un provider local, persistant, calculé, paginé ou distant.

Master-detail

Utiliser un DataCursor pour transporter l’objet courant depuis la vue maître. Un DataSet dépendant peut ensuite résoudre une collection ou projection relativement à cet objet. Un déplacement de curseur est un changement de contexte de vue ; il n’implique pas que l’objet métier a changé.

Accès distant local-first

Lorsque le provider est distant, conserver un cache DataSet local. Changements d’onglet, déplacement de ligne, filtres temporaires ou expansion de panneaux restent locaux par défaut. Recherche, sauvegarde, validation, synchronisation et transitions de processus peuvent franchir explicitement la frontière provider/Runtime.

Règle de déclaration

DataSet, DataSource et DataCursor appartiennent à la couche vue/cache. Ne pas leur appliquer kind=slot|attribute, réservé aux champs des facettes du modèle conceptuel.