Public cible
Débutants, étudiants et professionnels qui souhaitent acquérir une pratique structurée dans ce domaine.
Développer des composants d'accès aux données
Développer des composants d'accès aux données
Se connecter pour s'inscrireORM et accès aux données
Isoler la persistance, sécuriser les requêtes et rendre les transactions testables et indépendantes du moteur.
-
-
Objectifs
Comprendre les notions essentielles et les appliquer dans un projet vérifiable.
-
Prérequis
Aucune connaissance préalable n’est strictement obligatoire ; les prérequis détaillés sont précisés dans les ateliers.
-
Niveau
Bac+3
-
Ressources
- Documentation officielle et références citées dans les ateliers.
- Exercices, examens et projet de synthèse du catalogue.
-
Validation des compétences
La validation repose sur les évaluations actives et les livrables pratiques du cours.
-
Besoins techniques
Un ordinateur, un navigateur et les outils indiqués dans le premier atelier sont suffisants pour commencer.
Modules associés
Exercices, examens et projets
Accès aux données
Projet
Projet persistance
Livrer une couche de persistance documentée.
Livrables :
- Repository
- Tests
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.
À la fin du cours
- Construire un repository explicite et maintenable.
- Écrire des requêtes paramétrées et éviter les failles d’injection.
- Gérer transactions, pagination et erreurs de connexion.
- Tester les données avec une base réelle et des cas limites.
Organisation
Le cours alterne conception de repository, requêtes, transactions et tests.
Prérequis : SQL basics et compréhension des transactions.
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
Point de contrôle : Une méthode ne renvoie pas plus de données que celles nécessaire à son cas d’usage.
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)
Point de contrôle : Une chaîne contenant apostrophe, espace ou caractère spécial ne modifie pas la requête.
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
Point de contrôle : Un scénario d’échec ne laisse ni commande orpheline ni ligne partielle.
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
- Préparer un jeu minimal.
- Tester le chemin nominal et un cas limite.
- Vérifier le plan ou les index sur un volume réaliste.
Point de contrôle : Un rapport de test indique la requête, les paramètres et le résultat attendu.
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.
Critère de réussite : Le composant est validé lorsqu’un cas métier fonctionne, qu’une entrée hostile ne change pas la requête et qu’un rollback est démontré.
Publié le 29/11/2025