ASP.NET Core et Entity Framework Core

ASP.NET Core et Entity Framework Core

1. ASP.NET Core : le pipeline et ses interceptions

   Une requête ASP.NET Core traverse un pipeline ordonné. Chaque élément peut agir sur la requête avant qu'elle n'atteigne le contrôleur, ou sur la réponse au retour.

   L'ordre est le contrat

   Un intercepteur d'authentification placé après l'autorisation ne protège plus de rien ; une journalisation placée après le gestionnaire d'exceptions n'enregistrera pas les erreurs non gérées. Un composant mal placé est un composant inopérant, sans le moindre avertissement. C'est la première cause d'incident de production sur un pipeline d'authentification.

   Le risque direct : l'ordre des filtres

   Le piège le plus coûteux du modèle est l'exception filters : par défaut, une exception non gérée dans un contrôleur court-circuite la chaîne et part directement vers le middleware global. Le filtre d'exception placé sur le contrôleur n'est jamais appelé — la documentation le signale, et c'est la première cause d'erreurs rendues en 500 sans corps utile, alors que le gestionnaire prévu existe.

   Deux remèdes : rechercher explicitement l'exception dans le gestionnaire global, ou activer le court-circuit explicite. Le choix se documente, parce qu'il change le comportement du pipeline entier.

   La configuration : deux erreurs classiques

   • une clé de configuration en dur dans le code : le déploiement en préproduction utilise alors l'adresse de production, ou l'inverse. L'erreur apparaît au moment du test, pas avant ;
   • un secret en clair dans le fichier de configuration versionné. Les secrets passent par l'injection de variables d'environnement ou un coffre, jamais par le dépôt.

   Réflexe de vérification : la même exécution doit fonctionner avec deux fichiers de configuration différents, sans recompilation. Si le build produit exactement le même artefact partout, la configuration n'est pas injectée correctement.

   La gestion d'erreurs : la règle du statut

   Une API doit renvoyer un code de statut cohérent avec la situation : 400 pour une demande invalide, 401 pour une absence d'authentification, 403 pour un droit insuffisant, 404 pour une ressource absente, 409 pour un conflit d'état, 500 pour une erreur serveur. Le distinguer n'est pas cosmétique : 401 et 403 ne se traitent pas de la même façon côté client, et les confondre oblige le consommateur à deviner s'il doit rediriger vers une page de connexion ou afficher un message d'interdiction.

2. Entity Framework Core : requêtes, suivi, transactions

   Entity Framework Core est un mappeur relationnel : des objets en mémoire, des tables en base. Toute la difficulté tient à la frontière entre les deux mondes.

   Différé par défaut, c'est un piège

   Une requête LINQ est évaluée au dernier moment quand le résultat est parcouru, pas à l'écriture. Deux conséquences qu'il faut connaître par cœur :

   • une requête dans une boucle produit une requête par tour — le défaut N+1, la cause de ralentissement la plus fréquente sur ce type d'ORM ;
   • le nombre de requêtes surprises est visible dans les journaux : c'est le seul contrôle fiable, et il automatise mieux qu'un test d'intégration.

   Le remède est l'inclusion explicite des relations nécessaires, ou le chargement paresseux activé par défaut avec l'inclusion de toutes les relations. Choisir l'un plutôt que l'autre est un arbitrage : le second est simple, le premier est prévisible.

   Le suivi des entités change la sémantique

   Par défaut, Entity Framework suit les entités lues : il conserve leur état initial et applique automatiquement les modifications détectées au moment de l'enregistrement. Conséquence directe et peu évidente : modifier une propriété sur un objet lu suffit à déclencher une mise à jour, sans appel explicite. C'est confortable, et c'est dangereux : une propriété de navigation qu'on touche par erreur produit une écriture inattendue en base.

   La parade : utiliser des requêtes sans suivi pour la lecture seule, et traiter l'écriture dans un composant dédié et explicite.

   Les transactions : le défaut par omission

   Par défaut, aucune transaction n'est ouverte autour d'un SaveChanges pris isolément. Dans une opération qui modifie plusieurs tables, un échec au milieu laisse un état intermédiaire incohérent : la commande est enregistrée mais pas son ligne de détail. La transaction explicite autour de l'ensemble est l'une des trois seules garanties d'intégrité, avec les clés étrangères et les contraintes d'unicité.

   Les requêtes paramétrées

   Le générateur de SQL produit toujours des requêtes paramétrées : les valeurs ne sont jamais concaténées dans le texte SQL. C'est une garantie de l'ORM, et elle protège de l'injection à condition de ne pas contourner le générateur. Dès qu'on écrit du SQL à la main, la securite redevient une responsabilité du développeur, avec le paramétrage explicite comme seule parade.