Accès aux données

Syllabus

1. Description

2. Objectifs

3. Validations de compétences

4. Public cible

   Aucun public cible spécifié pour ce module.

5. Besoins techniques

6. Prérequis

   • Aucun prérequis

7. Niveau

8. Historique du module

   Aucune action enregistrée

Composants d’accès aux données

Isoler les requêtes, protéger les données et rendre la persistance remplaçable sans couples le domaine au moteur de base.

Repository et lecture explicite

Le repository expose les besoins du domaine, pas les tables. Nommer les méthodes par intention métier permet de changer SQL ou ORM sans modifier les règles métier.

Sélectionner les colonnes nécessaires, filtrer avant le chargement et définir un ordre stable. Une requête doit être lisible, limitée et associée à un test de résultat.

findAvailableRooms(DateTime $from, DateTime $to): array

Requêtes sûres et lisibles

Utiliser les paramètres liés et une liste de valeurs contrôlée. Ne jamais concaténer une saisie utilisateur dans une chaîne SQL. Échapper les valeurs reste moins sûr que les paramètres natifs.

Pour les recherches, construire une requête avec pagination et tri explicite. Indexer les colonnes réellement filtrées et éviter les fonctions qui empêchent l’index d’être utilisé.

$qb->andWhere("c.slug = :slug")->setParameter("slug", $slug)

Transactions et fiabilité

Une transaction doit protéger un ensemble d’écritures indivisible. Définir son point de début et de fin, puis tester le rollback après une erreur métier, une violation de contrainte ou une perte de connexion.

Ne pas placer une transaction longue autour d’un appel HTTP externe. Séparer les traitements et documenter le comportement attendu en cas de nouvelle tentative.

BEGIN → écrire la commande et ses lignes → COMMIT; sinon ROLLBACK

Tests et surveillance

Tester les résultats, les contraintes, la pagination et le comportement en cas de données absentes. Les tests unitaires du repository peuvent être complétés par une base éphémère pour les requêtes complexes.

Mesurer la latence, le nombre de requêtes et les erreurs de connexion. Un repository lent ou silencieusement en échec est un problème d’observabilité avant d’être un problème de syntaxe.

Méthode

1. Préparer un jeu minimal.
2. Tester le chemin nominal et un cas limite.
3. Vérifier le plan ou les index sur un volume réaliste.

Livrables et validation

Le livrable doit montrer une compréhension personnelle, des choix explicités et une vérification par un cas de test ou une procédure reproductible.

• Un repository avec méthodes métier documentées.
• Un catalogue de requêtes paramétrées et indexées.
• Une stratégie de transaction et de rollback.
• Une suite de tests avec jeu de données et critères de performance.

Exercices, examens et projets