Liaison de données avec EF Core

Démarrez la console de données Support Desk en décidant quels objets sont actifs pour une session et lesquels sont actifs pour une opération de base de données. Les formulaires Wisej.NET conservent l'état utilisateur, mais un Context de base de données Entity Framework doit représenter une courte unité de travail.

Le modèle de programmation côté serveur semble familier car les contrôles, les gestionnaires d'événements et les sources de liaison restent ensemble. Ne donnez pas au Context la même durée de vie. Créez-le pour une requête ou une modification, enregistrez-le si nécessaire, puis supprimez-le au lieu de le conserver comme état d'interface.

Séparez l’état de session, les objets d’interface, les requêtes individuelles et le travail de base de données. Une opération attendue peut reprendre sur un autre thread et un Context n'est pas thread-safe. Le conserver sous une forme à long terme conserve également les entités suivies longtemps après l'opération qui en avait besoin.

Utilisez AddDbContextFactory par défaut afin que la recherche, la recherche, l'enregistrement et la suppression puissent chacun posséder un nouveau Context. Un Context d'éditeur modal de plus longue durée est une exception délibérée : gardez-le privé, protégez l'accès et supprimez-le à la fermeture de cet éditeur.

Enregistrez la fabrique de Context dans le fournisseur d’injection de dépendances à l’aide des informations de connexion configurées. Reliez ce fournisseur à Wisej.NET afin que les pages résolvent les mêmes services enregistrés. Limitez les paramètres de diagnostic au développement et évitez d’introduire un deuxième conteneur de services concurrent.

TicketQueryService stocke la fabrique, pas un Context partagé. Chaque méthode crée et supprime son propre Context avant de revenir. Cela empêche les modifications suivies par un utilisateur de partager un Context avec la requête d’un autre utilisateur et évite l’accès simultané à ce Context.

Conservez les enregistrements, les filtres, les modifications en attente et les sources de liaison sélectionnés dans leur session. Le stockage statique partagé ne convient que pour le matériel immuable véritablement partagé, tel que les données de référence. Une opération en arrière-plan crée également son propre Context au lieu d’emprunter l’état du formulaire.

Count démontre toute la limite de l'opération. Le garde-chargement empêche une seconde soumission pendant qu'un nouveau Context compte les tickets. Lorsque la base de données n'est pas disponible, l'erreur conviviale explique l'échec et le nettoyage final restaure le bouton pour une autre tentative.

Créez les couches de solution et l'enregistrement d'usine, puis résolvez le service de requête à partir d'une page et exécutez le décompte asynchrone. Incluez l’usine au moment de la conception. Votre examen doit être capable d'identifier où chaque Context est créé et supprimé, sans Context statique nulle part.

Définissez le schéma Support Desk avant de vous fier aux écrans liés aux données. Le modèle Entity Framework relie les attentes de l'interface aux règles de base de données. La configuration des relations, des index et de la concurrence rend délibérément ce contrat révisable au lieu de le laisser à des défauts accidentels.

Regardez les échecs que le schéma doit éviter : une recherche de file d'attente non indexée, deux agents écrasant un ticket et une base de données corrigée manuellement divergeant de la version suivante. Chaque problème appelle un modèle ou une décision de migration différent.

Gardez Ticket au centre des relations entre entités, avec de petites entités de recherche et des commentaires comme détail. L'agent facultatif et la valeur de version ont des significations distinctes. Utilisez un élément de liste plate distinct pour la grille au lieu d'exposer l'intégralité du graphique.

Utilisez des annotations simples là où elles sont suffisantes et collectez la configuration de la base de données de production dans OnModelCreating. La configuration fluide exprime ensemble les longueurs, les valeurs requises, les index, la précision, les valeurs par défaut et le comportement des relations, gardant les décisions de mappage de base de données proches du Context.

Exigez un titre délimité et configurez RowVersion pour la simultanéité. Créez des index autour des recherches réellement effectuées par l'application, y compris le statut avec la date d'échéance. Un comportement de suppression explicite fait de l'effet sur les enregistrements associés un choix révisé plutôt qu'une surprise.

La mise à jour correspond à la fois à l’identifiant du ticket et à la version initialement lue. Si un autre agent a modifié cette version, aucune ligne ne correspond. Entity Framework signale un conflit de concurrence, permettant à l'application d'expliquer la collision au lieu de remplacer silencieusement le travail de quelqu'un d'autre.

Examinez une migration comme toute autre modification de source avant de l’appliquer. Le développement peut appliquer directement la migration révisée ; la production reçoit un script ou un bundle reproductible approuvé. Cela maintient les modifications de schéma liées à la révision de la version plutôt qu'à plusieurs instances d'application qui s'exécutent au démarrage.

Offrez à l’usine au moment de la conception le même fournisseur avec une connexion de développement local sécurisée. Les outils de migration peuvent ensuite créer le modèle sans démarrer Wisej.NET. La séparation de ce chemin rend la génération de schéma indépendante du comportement de démarrage de l'exécution de l'application.

Générez InitialCreate, inspectez les modifications planifiées, puis appliquez-les pour créer les tables, la colonne de version et les index. Semez à travers un Context éphémère. Les exemples de clients, d'agents, de catégories et de tickets qui en résultent fournissent aux leçons ultérieures une base de données cohérente à utiliser.

Fournissez les cinq entités associées avec des règles de suppression explicites, les index planifiés et RowVersion. Ajoutez l'usine au moment de la conception et examinez la migration initiale, puis amorcez la base de données de développement. La remise doit démontrer que le modèle et le schéma généré concordent.

Créez un navigateur de tickets qui se charge de manière asynchrone et lie ses résultats via BindingSource. L'écran a besoin d'une liste stable pour l'affichage, tandis que le service de requête n'a besoin que d'une courte opération de base de données. La séparation de ces responsabilités maintient l’état de l’interface indépendant du Context.

Sélectionnez uniquement les champs nécessaires aux sept colonnes de la grille dans TicketListItem. Une projection sans suivi renvoie moins de données et évite de conserver un graphique d'entité modifiable. La liste du navigateur peut alors survivre au contexte de la requête sans faire partie du travail de l’éditeur.

Composez la requête avant de l'exécuter : ajoutez les filtres, l'ordre, les limites de page et la projection. ToListAsync matérialise alors une seule fois les résultats demandés. Cela donne à la base de données le travail de filtrage et de pagination au lieu de tout charger et de le découper dans l'interface.

Dans TicketQueryService, créez un Context et ajoutez uniquement les filtres sélectionnés par l'utilisateur. Comptez les correspondances, puis récupérez la page projetée. La requête reste une description jusqu'au point d'exécution asynchrone, rendant le fonctionnement de sa base de données explicite dans la méthode.

Liez la liste matérialisée à BindingSource et liez la grille à cette source. Ne remettez pas à la grille un ensemble de bases de données en direct. Chargez les choix de recherche avant la première recherche et distinguez leur texte affiché de la clé stockée comme valeur sélectionnée.

La page coordonne l'expérience utilisateur autour d'un appel de service attendu. Définissez la protection de chargement, désactivez les commandes et affichez l'état avant le chargement. Attribuez la liste renvoyée, puis restaurez les contrôles dans finally afin que le succès et l'échec laissent une page utilisable.

Recherchez avec le texte et le statut, puis comparez les cinquante lignes visibles avec le nombre total de correspondances. Next Page effectue une autre requête avec une nouvelle limite de page. Seuls les résultats projetés parviennent au navigateur ; le serveur ne transfère pas le graphique d'entité sous-jacent.

Testez délibérément le chemin du serveur inaccessible. L'opérateur devrait recevoir un message utile et reprendre la recherche après le nettoyage. Une tentative ultérieure crée un nouveau Context, de sorte qu'une opération ayant échoué ne laisse pas l'écran lié à un objet de base de données ayant échoué.

Fournissez le navigateur avec son modèle de liste, ses critères de recherche, son service de requête et sa grille liée. Chargez d'abord les recherches et incluez la recherche, la pagination avant et arrière avec un nombre total. Vérifiez les protections de chargement et la récupération dans le cadre du même flux de travail.

Transformez la boîte de dialogue du ticket en une limite d'édition sécurisée. L'utilisateur dispose des commandes familières Enregistrer, Annuler et Supprimer, tandis que le serveur contrôle quand l'entrée atteint le modèle et quand Entity Framework l'écrit. Le formulaire modal ne doit pas devenir un Context de base de données permanent.

Avant d’enregistrer ou de supprimer, appliquez la partie du contrat qui revient au serveur : terminez les modifications en attente, créez un nouveau Context pour l’opération et évitez les soumissions en double. Une boîte de dialogue familière n'est fiable que lorsque ces étapes cachées correspondent à ce que promettent les boutons.

Connectez les commandes à TicketEditModel via BindingSource et choisissez quand chaque valeur est mise à jour. Text et mises à jour des dates lors de la validation ; les recherches sont mises à jour à mesure que leurs propriétés changent. Les méthodes d'édition BindingSource gèrent l'élément courant, mais aucune d'entre elles ne remplace une sauvegarde en base de données.

Choisissez la limite de liaison en fonction des responsabilités de l'éditeur. La liaison directe d’entité peut convenir à un agrégat de courte durée avec un Context privé. Un modèle d'édition rend explicites la validation et les mises à jour partielles autorisées et évite de traiter une projection de grille en lecture seule comme une entité modifiable.

Suivez une séquence de sauvegarde : gardez, terminez les modifications, validez, chargez ou créez avec un nouveau Context, mappez les valeurs autorisées et enregistrez. Fermez avec succès uniquement une fois la persistance réussie. Gérez la concurrence séparément des autres pannes de base de données afin que l'utilisateur reçoive la bonne explication.

Dans SaveAsync, inspectez la commande plutôt que uniquement les noms de méthodes. EndEdit doit précéder la validation ; la création du Context suit les entrées acceptées. Le chargement par clé et le mappage à partir du modèle d'édition définissent ce qui est écrit, tandis que finally libère la garde de sauvegarde à chaque sortie.

La suppression commence par une confirmation, puis recharge le ticket par clé dans un nouveau Context. S'il a déjà disparu, expliquez-le au lieu de le traiter comme une suppression normale. Vérifiez la règle métier avant de supprimer et d’enregistrer l’enregistrement.

Modifiez le titre et l'urgence dans l'éditeur modal, puis enregistrez. L'état occupé couvre la persistance et un résultat de dialogue réussi ferme l'éditeur. Le navigateur parent effectue une nouvelle recherche, de sorte que la ligne affichée provient de l'état de la base de données enregistrée plutôt que d'hypothèses concernant la modification.

Créez des formulaires d'ajout et de modification autour de TicketEditModel, BindingSource et ErrorProvider. Inclut le chargement, la sauvegarde protégée, la suppression confirmée et l'actualisation parent. Vérifiez que l'annulation d'une modification et la réussite d'une sauvegarde produisent des effets différents et prévisibles sur le navigateur.

Ajoutez une validation avant que l'éditeur de tickets n'atteigne la base de données. Les utilisateurs ont besoin d'une explication sur laquelle ils peuvent agir, tandis que le serveur a encore besoin de contrôles finaux de cohérence. Ce module connecte les règles du modèle, les commentaires sur le terrain et la gestion des pannes de base de données en une seule expérience de sauvegarde compréhensible.

Conservez les trois couches de validation car elles protègent des limites différentes. Les vérifications d'interface fournissent des conseils immédiats, les règles de domaine s'appliquent également en dehors de ce formulaire et les contraintes de base de données protègent la cohérence finale. Passer la première couche ne supprime pas la nécessité des autres.

Ne supposez pas que SaveChangesAsync exécute les annotations du modèle d'édition. L'attribut Required permet de décrire le mappage sur une entité, mais le modèle d'entrée nécessite un appel de validation explicite. TryValidateObject est l'étape qui transforme ces règles déclarées en contrôles réels.

TicketValidator renvoie les noms de champs et les messages après l'exécution des annotations et de la règle de ticket fermé. Il ne dépend pas des contrôles Wisej.NET, les cas négatifs peuvent donc être testés sans ouvrir de formulaire. L'interface décide ensuite où afficher chaque résultat.

Effacez les anciens commentaires, terminez la modification et validez le modèle actuel avant de créer un Context. Acheminez chaque résultat vers son entrée et également vers le résumé. Le retour à ce stade empêche les données non valides de démarrer une opération de base de données inutile.

Gardez la validation et la gestion des exceptions dans le bon ordre. Retours d'entrée non valides avant l'enregistrement ; une exception de concurrence est interceptée avant les exceptions de base de données plus larges. Enregistrez les détails techniques sur le serveur, actualisez les recherches si nécessaire et restaurez toujours l'enregistrement dans finally.

Combinez un titre vide avec une date d'échéance future sur un ticket fermé. Les deux entrées devraient recevoir des commentaires utiles et apparaître dans le résumé, tandis que Enregistrer reste indisponible. Corrigez les deux valeurs pour confirmer que la compensation des erreurs suit la validité actuelle du modèle.

Un modèle d'entrée valide peut toujours échouer lorsqu'un autre agent crée le même numéro de ticket. L'index unique rejette le doublon lors de l'enregistrement. Traduisez cet échec en une explication claire pour l'utilisateur, tout en conservant les détails de la base de données uniquement dans le journal de diagnostic.

Fournissez ensemble le modèle d'édition annoté, le validateur indépendant, les commentaires sur le terrain et le résumé. Ajoutez la traduction du numéro en double et laissez Enregistrer désactivé en cas de saisie non valide. Les cinq tests négatifs devraient exercer directement les règles, prouvant qu'elles ne dépendent pas d'une forme visible.

Utilisez le navigateur de tickets lent pour mesurer ce que fait réellement la base de données. L'objectif est une requête projetée et paginée avec des preuves du journal. La comparaison de la même recherche avant et après montre si l'amélioration vient d'une diminution du travail plutôt que d'une impression visuelle.

Le formatage des cellules semble inoffensif jusqu'à ce que la lecture d'une propriété de navigation déclenche un chargement paresseux. La requête de ticket initiale est suivie de requêtes de données associées pour chaque ligne. Comptez ces instructions pour expliquer pourquoi l'affichage de cinquante lignes peut produire cent cinquante et une commandes de base de données.

Choisissez le chargement des données associées en fonction du résultat dont vous avez besoin. La projection s'adapte à un modèle d'affichage plat ; Include s'adapte à un agrégat contrôlé, avec filtrage ou chargement explicite le cas échéant. Évitez les accès de navigation paresseux dans la grille car son coût de base de données est caché dans le code de présentation.

Utilisez le suivi lorsque l'éditeur enregistre les mêmes instances d'entité. Les listes en lecture seule, les recherches, les exportations et les tableaux de bord n'en ont généralement pas besoin. La résolution d'identité est un choix distinct pour un graphique en lecture seule qui nécessite toujours une instance pour chaque entité répétée.

Filtrez sur les colonnes indexées, comptez les correspondances et récupérez une page de cinquante éléments de liste projetés. La sélection de noms associés dans la requête permet à la base de données de les rejoindre une fois. Le formatage des lignes renvoyées utilise ensuite les valeurs disponibles au lieu de provoquer des lectures supplémentaires dans la base de données.

Activez la journalisation des commandes dans le développement avant de choisir une optimisation. Examinez le nombre et la durée des commandes pour localiser le goulot d’étranglement. Les requêtes compilées, le regroupement, les requêtes fractionnées ou les instructions de base de données brutes doivent répondre à un besoin mesuré et non ajouter de la complexité avant que la requête ordinaire ne soit comprise.

Comparez les recherches enregistrées : cent cinquante et une requêtes deviennent deux, le décompte total étant toujours présent. La durée mesurée tombe à trente-huit millisecondes. La recherche et la pagination restent désactivées pendant le chargement, de sorte que le chemin de base de données plus rapide préserve également le comportement coordonné de l'interface.

Attendez une opération avant d’en démarrer une autre sur le même Context. Pour un traitement en arrière-plan plus long, créez le Context dans Application.StartTask et signalez la progression via Application.Update. Garder la propriété locale de la tâche évite de partager un Context sur des opérations simultanées d'interface et d'arrière-plan.

Enregistrez les commandes et la durée d'origine, puis remplacez la requête de grille par une projection sans suivi et des pages de cinquante lignes. Supprimez les lectures de navigation paresseuses du code de présentation. Votre note avant et après doit relier l’amélioration mesurée au travail de base de données qui a été éliminé.

Terminez la console Support Desk en protégeant les modifications effectuées au cours de différentes sessions. Deux opérateurs peuvent ouvrir le même ticket, donc une sauvegarde réussie ne doit pas effacer silencieusement une modification effectuée depuis le chargement de l'éditeur. Le projet final relie cette protection au déploiement et aux diagnostics.

Dana ferme le ticket tandis que Priya a encore une ancienne édition ouverte. Enregistrer le changement de priorité de Priya sans vérifier la version originale pourrait restaurer l'ancien statut. RowVersion détecte que l'enregistrement a été modifié, transformant un écrasement silencieux en conflit explicite.

Emportez la version que l'utilisateur a réellement vue dans TicketEditModel. Lors de l'enregistrement avec une entité fraîchement chargée, attribuez cette version transportée comme valeur d'origine. Sinon, le Context serait comparé à sa nouvelle lecture, manquant les modifications apportées pendant l'édition par l'utilisateur.

Après avoir restauré la version originale, interceptez l'exception de concurrence et inspectez chaque entrée affectée. Lisez les valeurs actuelles de la base de données pour créer la liste des conflits ; une ligne de base de données manquante signifie une suppression. Comparez les différentes propriétés afin que la boîte de dialogue puisse expliquer la collision réelle.

Présentez le conflit en utilisant les noms de champs et les valeurs de l'utilisateur, de la base de données et d'origine. Reload accepte les données actuelles de la base de données ; l'écrasement nécessite une autorisation de stratégie, tandis que la fusion décide par champ. Après la résolution, actualisez la grille pour que l'écran environnant soit conforme au résultat choisi.

Un SaveChangesAsync fournit déjà une transaction pour ses modifications. Utilisez une transaction explicite lorsque plusieurs opérations doivent réussir ensemble. Lorsque la nouvelle tentative est activée, placez l'unité entière dans la stratégie d'exécution afin qu'une nouvelle tentative répète la transaction complète plutôt qu'un fragment isolé.

Conservez les secrets de connexion de production en dehors du code source et déployez des migrations reproductibles révisées lors de la publication. Désactivez la journalisation des données sensibles en dehors du développement. Testez les services indépendamment de l'interface, à l'aide d'une base de données relationnelle où le comportement testé dépend de règles relationnelles.

Exécutez la collision en deux sessions : Dana enregistre d'abord, puis Priya voit l'état et la priorité en conflit à côté des valeurs de la base de données. Choisir Recharger met à jour la version de l’éditeur et actualise la grille. Le résultat visible démontre que la sauvegarde obsolète a été arrêtée plutôt que silencieusement acceptée.

Examinez la console comme un seul système connecté : navigateur projeté, chargement de la recherche, modification du modèle, commentaires, gardes et vérification de version. Le plan de migration et la note d'architecture expliquent comment il reste maintenable. L'évaluation récompense ensemble l'architecture, la liaison et l'exactitude du Entity Framework.

Soumettez un conflit reproductible de deux sessions avec la version originale effectuée lors de l'enregistrement et une boîte de dialogue de résolution claire. Incluez les notes de déploiement, le script de migration révisé et les paramètres de journalisation sécurisés. L’examen de synthèse devrait être en mesure de répéter le conflit et de vérifier sa résolution.