Reconstitution de la logique des produits

L’ingénierie à rebours est le processus de génération de modèles automatique des classes de type d’entité et une classe DbContext basée sur un schéma de base de données. il peut être effectué à l’aide Scaffold-DbContext de la commande des outils de la Console EF Core Gestionnaire de package (PMC) ou dotnet ef dbcontext scaffold de la commande des outils de l’Interface de ligne de commande (CLI) .net.

Prérequis

  • avant l’ingénierie à rebours, vous devez installer les outils PMC (Visual Studio uniquement) ou les outils CLI. Pour plus d’informations, consultez les liens.
  • installez le package NuGet pour Microsoft.EntityFramework.Design dans le projet sur lequel vous effectuez la génération de modèles automatique.
  • Vous devez également installer un fournisseur de base de données approprié pour le schéma de base de données que vous souhaitez rétroconcevoir.

Chaîne de connexion

Le premier argument de la commande est une chaîne de connexion à la base de données. Les outils utilisent cette chaîne de connexion pour lire le schéma de la base de données.

La façon dont vous utilisez les guillemets et les séquences d’échappement de la chaîne de connexion dépend du shell que vous utilisez pour exécuter la commande. Reportez-vous à la documentation de votre shell pour obtenir des informations spécifiques. Par exemple, PowerShell vous oblige à placer le caractère dans une séquence d’échappement $ , mais pas \ .

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook" Microsoft.EntityFrameworkCore.SqlServer

Configuration et secrets de l’utilisateur

si vous avez un projet ASP.NET Core, vous pouvez utiliser la Name=<connection-string> syntaxe pour lire la chaîne de connexion à partir de la configuration.

Cela fonctionne bien avec l' outil secret Manager pour conserver le mot de passe de votre base de données distinct de votre code base.

dotnet user-secrets set ConnectionStrings:Chinook "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook"
dotnet ef dbcontext scaffold Name=ConnectionStrings:Chinook Microsoft.EntityFrameworkCore.SqlServer

Nom du fournisseur

Le deuxième argument est le nom du fournisseur. le nom du fournisseur est généralement identique au nom du package NuGet du fournisseur.

Spécification de tables

Toutes les tables du schéma de base de données sont rétroconçues dans les types d’entités par défaut. Vous pouvez limiter les tables qui sont rétroconçues en spécifiant des schémas et des tables.

L' --schema option peut être utilisée pour inclure chaque table dans un schéma, tandis que --table peut être utilisé pour inclure des tables spécifiques.

Pour inclure plusieurs tables, spécifiez l’option plusieurs fois :

dotnet ef dbcontext scaffold ... --table Artist --table Album

Préservation des noms

Les noms de table et de colonne sont fixes pour mieux correspondre aux conventions de nommage .NET pour les types et les propriétés par défaut. Si vous spécifiez le -UseDatabaseNames commutateur dans PMC ou l' --use-database-names option dans le CLI .net Core désactivez ce comportement en conservant autant que possible les noms de bases de données d’origine. Les identificateurs .NET non valides seront toujours fixes et les noms synthétisés, tels que les propriétés de navigation, seront toujours conformes aux conventions d’affectation de noms .NET.

API Fluent ou annotations de données

les types d’entités sont configurés à l’aide de l’API Fluent par défaut. Spécifiez -DataAnnotations (PMC) ou --data-annotations (CLI .net Core) pour utiliser à la place des annotations de données lorsque cela est possible.

par exemple, l’utilisation de l’API Fluent générera un modèle de structure :

entity.Property(e => e.Title)
    .IsRequired()
    .HasMaxLength(160);

Lorsque vous utilisez des annotations de données, vous générez une structure :

[Required]
[StringLength(160)]
public string Title { get; set; }

Nom de DbContext

Le nom de classe DbContext généré par génération de modèles automatique sera le nom de la base de données suffixée par défaut . Pour spécifier un autre, utilisez -Context dans PMC et --context dans le CLI .net core.

Répertoires et espaces de noms

Les classes d’entité et une classe DbContext sont intégrées au répertoire racine du projet et utilisent l’espace de noms par défaut du projet.

Vous pouvez spécifier le répertoire dans lequel les classes sont échafaudées à l’aide de --output-dir , et --context-dir peut être utilisé pour générer un modèle de structure de la classe DbContext dans un répertoire distinct de celui des classes de type d’entité :

dotnet ef dbcontext scaffold ... --context-dir Data --output-dir Models

Par défaut, l’espace de noms est l’espace de noms racine, ainsi que les noms de tous les sous-répertoires sous le répertoire racine du projet. Toutefois, à partir de EFCore 5,0, vous pouvez remplacer l’espace de noms pour toutes les classes de sortie à l’aide de --namespace . Vous pouvez également remplacer l’espace de noms uniquement pour la classe DbContext à l’aide des --context-namespace éléments suivants :

dotnet ef dbcontext scaffold ... --namespace Your.Namespace --context-namespace Your.DbContext.Namespace

Fonctionnement

L’ingénierie à rebours commence par lire le schéma de base de données. Il lit les informations sur les tables, les colonnes, les contraintes et les index.

Ensuite, il utilise les informations de schéma pour créer un modèle de EF Core. Les tables sont utilisées pour créer des types d’entité ; les colonnes sont utilisées pour créer des propriétés. et les clés étrangères sont utilisées pour créer des relations.

Enfin, le modèle est utilisé pour générer le code. les classes de type d’entité, l’API Fluent et les annotations de données correspondantes sont échafaudées afin de recréer le même modèle à partir de votre application.

Limites

  • Tout ce qui concerne un modèle peut être représenté à l’aide d’un schéma de base de données. Par exemple, les informations sur les hiérarchies d’héritage, les types détenuset le fractionnement de table ne sont pas présentes dans le schéma de la base de données. Pour cette raison, ces constructions ne feront jamais l’effet d’une rétroconception.
  • En outre, certains types de colonne peuvent ne pas être pris en charge par le fournisseur EF Core. Ces colonnes ne sont pas incluses dans le modèle.
  • Vous pouvez définir des jetons d’accès concurrentiel, dans un modèle EF Core pour empêcher deux utilisateurs de mettre à jour la même entité en même temps. certaines bases de données ont un type spécial pour représenter ce type de colonne (par exemple, rowversion dans SQL Server), auquel cas nous pouvons rétroconcevoir ces informations. toutefois, les autres jetons d’accès concurrentiel ne feront pas l’affaire d’une rétroconception.
  • Avant le EF Core 6, la fonctionnalité de type référence Nullable de C# 8 n’était pas prise en charge dans l’ingénierie à rebours : EF Core toujours généré du code C# qui supposait que la fonctionnalité était désactivée. par exemple, les colonnes de texte nullable ont été créées en tant que propriété de type string , et non string? avec l’API Fluent ou les annotations de données utilisées pour configurer si une propriété est requise ou non. Si vous utilisez une version antérieure de EF Core, vous pouvez toujours modifier le code de génération de modèles automatique et les remplacer par des annotations de possibilité de valeur null.

Personnalisation du modèle

Le code généré par EF Core est votre code. N’hésitez pas à la modifier. Elle sera régénérée uniquement si vous retrouvez à nouveau le même modèle. Le code de génération de modèles automatique représente un modèle qui peut être utilisé pour accéder à la base de données, mais ce n’est certainement pas le seul modèle qui peut être utilisé.

Personnalisez les classes de type d’entité et la classe DbContext en fonction de vos besoins. Par exemple, vous pouvez choisir de renommer des types et des propriétés, d’introduire des hiérarchies d’héritage ou de fractionner une table en plusieurs entités. Vous pouvez également supprimer des index non uniques, des séquences inutilisées et des propriétés de navigation, des propriétés scalaires facultatives et des noms de contrainte à partir du modèle.

Vous pouvez également ajouter des constructeurs, des méthodes, des propriétés, etc. supplémentaires. utilisation d’une autre classe partielle dans un fichier séparé. Cette approche fonctionne même lorsque vous envisagez de réactiver le modèle.

Mise à jour du modèle

Après avoir apporté des modifications à la base de données, vous devrez peut-être mettre à jour votre modèle de EF Core pour refléter ces modifications. Si les modifications de la base de données sont simples, il peut être plus facile d’apporter manuellement les modifications à votre modèle de EF Core. Par exemple, le fait de renommer une table ou une colonne, de supprimer une colonne ou de mettre à jour le type d’une colonne est une modification triviale dans le code.

Toutefois, les modifications les plus importantes ne sont pas aussi faciles à effectuer manuellement. Un flux de travail courant consiste à rétroconcevoir à nouveau le modèle à partir de la base de données en utilisant -Force (PMC) ou --force (CLI) pour remplacer le modèle existant par un modèle mis à jour.

Une autre fonctionnalité couramment demandée est la possibilité de mettre à jour le modèle à partir de la base de données tout en préservant la personnalisation, comme les renommages, les hiérarchies de types, etc. Utilisez #831 de problème pour suivre la progression de cette fonctionnalité.

Avertissement

Si vous rérétroconcevez le modèle à partir de la base de données, toutes les modifications que vous avez apportées aux fichiers seront perdues.

Conseil

si vous utilisez Visual Studio, l’extension de la communauté outils EF Core Power Tools , un outil graphique qui s’appuie sur les outils de ligne de commande EF Core, offre des options de personnalisation et de flux de travail supplémentaires.