Partager via

Paramètres du fichier de configuration

  • Article

Entity Framework permet de spécifier un certain nombre de paramètres à partir du fichier de configuration. En général, EF suit une « convention sur le principe de configuration » : tous les paramètres abordés dans ce billet ont un comportement par défaut, vous devez uniquement vous soucier de modifier le paramètre lorsque la valeur par défaut ne répond plus à vos besoins.

Recommandations en matière de données de configuration

  • Ne stockez jamais des mots de passe ou d’autres données sensibles dans le code du fournisseur de configuration ou dans les fichiers de configuration en texte clair.
  • N’utilisez aucun secret de production dans les environnements de développement ou de test.
  • Spécifiez les secrets en dehors du projet afin qu’ils ne puissent pas être validés par inadvertance dans un référentiel de code source.
  • Envisagez de protéger le contenu du fichier de configuration à l’aide de la configuration protégée.

Avertissement

Cet article utilise une base de données locale qui ne nécessite pas l’authentification des utilisateurs. Les applications de production doivent utiliser le flux d’authentification le plus sécurisé disponible. Pour plus d’informations sur l’authentification pour les applications de test et de production déployées, consultez Flux d’authentification sécurisés.

Alternative basée sur le code

Tous ces paramètres peuvent également être appliqués à l’aide du code. À compter d’EF6, nous avons introduit configuration basée sur le code, qui fournit un moyen central d’appliquer la configuration à partir du code. Avant EF6, la configuration peut toujours être appliquée à partir du code, mais vous devez utiliser différentes API pour configurer différentes zones. L’option de fichier de configuration permet de modifier facilement ces paramètres pendant le déploiement sans mettre à jour votre code.

Section Configuration d’Entity Framework

À compter d’EF4.1, vous pouvez définir l’initialiseur de base de données pour un contexte à l’aide de la section appSettings du fichier de configuration. Dans EF 4.3, nous avons introduit la section entityFramework personnalisée pour gérer les nouveaux paramètres. Entity Framework reconnaît toujours les initialiseurs de base de données définis à l’aide de l’ancien format, mais nous vous recommandons de passer au nouveau format si possible.

La section entityFramework a été automatiquement ajoutée au fichier de configuration de votre projet lorsque vous avez installé le package NuGet EntityFramework.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework"
       type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </configSections>
</configuration>

Chaînes de connexion

Cette page fournit plus d’informations sur la façon dont Entity Framework détermine la base de données à utiliser, y compris les chaînes de connexion dans le fichier de configuration.

Les chaînes de connexion vont dans l’élément connectionStrings standard et ne nécessitent pas la section entityFramework.

Les modèles basés sur le code first utilisent des chaînes de connexion normales ADO.NET. Par exemple :

<connectionStrings>
  <add name="BlogContext"  
        providerName="System.Data.SqlClient"  
        connectionString="Server=.\SQLEXPRESS;Database=Blogging;Integrated Security=True;"/>
</connectionStrings>

Les modèles basés sur EF Designer utilisent des chaînes de connexion EF spéciales. Par exemple :

<connectionStrings>
  <add name="BlogContext"  
    connectionString=
      "metadata=
        res://*/BloggingModel.csdl|
        res://*/BloggingModel.ssdl|
        res://*/BloggingModel.msl;
      provider=System.Data.SqlClient;
      provider connection string=
        &quot;data source=(localdb)\mssqllocaldb;
        initial catalog=Blogging;
        integrated security=True;
        multipleactiveresultsets=True;&quot;"
     providerName="System.Data.EntityClient" />
</connectionStrings>

Type de configuration basé sur le code (EF6 et versions ultérieures)

À compter d’EF6, vous pouvez spécifier DbConfiguration pour EF à utiliser pour configuration basée sur le code dans votre application. Dans la plupart des cas, vous n’avez pas besoin de spécifier ce paramètre, car EF découvre automatiquement votre DbConfiguration. Pour plus d’informations sur le moment où vous devrez peut-être spécifier DbConfiguration dans votre fichier de configuration, consultez la section Déplacement de DbConfiguration de configuration basée sur le code.

Pour définir un type DbConfiguration, vous spécifiez le nom du type qualifié d’assembly dans l’élément codeConfigurationType.

Remarque

Un nom qualifié d’assembly est le nom qualifié de l’espace de noms, suivi d’une virgule, puis de l’assembly dans lequel réside le type. Vous pouvez également spécifier la version de l’assembly, la culture et le jeton de clé publique.

<entityFramework codeConfigurationType="MyNamespace.MyConfiguration, MyAssembly">
</entityFramework>

Fournisseurs de base de données EF (EF6 et versions ultérieures)

Avant EF6, les parties spécifiques à Entity Framework d’un fournisseur de base de données devaient être incluses dans le cadre du fournisseur principal ADO.NET. À compter d’EF6, les parties spécifiques EF sont désormais gérées et enregistrées séparément.

Normalement, vous n’aurez pas besoin d’inscrire vous-même des fournisseurs. Cela sera généralement effectué par le fournisseur lorsque vous l’installez.

Les fournisseurs sont inscrits en incluant un élément fournisseur sous la section des fournisseurs enfant de la section entityFramework . Il existe deux attributs requis pour une entrée de fournisseur :

  • invariantName identifie le fournisseur de ADO.NET principal cible par ce fournisseur EF
  • type est le nom de type qualifié d’assembly de l’implémentation du fournisseur EF

Remarque

Un nom qualifié d’assembly est le nom qualifié de l’espace de noms, suivi d’une virgule, puis de l’assembly dans lequel réside le type. Vous pouvez également spécifier la version de l’assembly, la culture et le jeton de clé publique.

Par exemple, voici l’entrée créée pour inscrire le fournisseur SQL Server par défaut lorsque vous installez Entity Framework.

<providers>
  <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
</providers>

Intercepteurs (EF6.1 à partir)

À compter d’EF6.1, vous pouvez inscrire des intercepteurs dans le fichier de configuration. Les intercepteurs vous permettent d’exécuter une logique supplémentaire quand EF effectue certaines opérations, telles que l’exécution de requêtes de base de données, l’ouverture de connexions, etc.

Les intercepteurs sont inscrits en incluant un élément intercepteur sous la section enfant intercepteurs de la section entityFramework. Par exemple, la configuration suivante inscrit le DatabaseLogger intégré intercepteur qui journalise toutes les opérations de base de données dans la console.

<interceptors>
  <interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework"/>
</interceptors>

Journalisation des opérations de base de données dans un fichier (EF6.1 à partir de)

L’inscription d’intercepteurs via le fichier config est particulièrement utile lorsque vous souhaitez ajouter la journalisation à une application existante pour faciliter le débogage d’un problème. DatabaseLogger prend en charge la journalisation dans un fichier en fournissant le nom de fichier en tant que paramètre de constructeur.

<interceptors>
  <interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
    <parameters>
      <parameter value="C:\Temp\LogOutput.txt"/>
    </parameters>
  </interceptor>
</interceptors>

Par défaut, le fichier journal sera remplacé par un nouveau fichier chaque fois que l’application démarre. À la place, ajoutez au fichier journal s’il existe déjà quelque chose comme :

<interceptors>
  <interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
    <parameters>
      <parameter value="C:\Temp\LogOutput.txt"/>
      <parameter value="true" type="System.Boolean"/>
    </parameters>
  </interceptor>
</interceptors>

Pour plus d’informations sur DatabaseLogger et l’inscription d’intercepteurs, consultez le billet de blog EF 6.1 : activation de la journalisation sans recompiler.

Fabrique de connexion par défaut du code

La section configuration vous permet de spécifier une fabrique de connexion par défaut que Code First doit utiliser pour localiser une base de données à utiliser pour un contexte. La fabrique de connexion par défaut est utilisée uniquement lorsqu’aucune chaîne de connexion n’a été ajoutée au fichier de configuration pour un contexte.

Lorsque vous avez installé le package NuGet EF, une fabrique de connexion par défaut a été inscrite qui pointe vers SQL Express ou LocalDB, selon celle que vous avez installée.

Pour définir une fabrique de connexion, vous spécifiez le nom de type qualifié d’assembly dans l’élément defaultConnectionFactory .

Remarque

Un nom qualifié d’assembly est le nom qualifié de l’espace de noms, suivi d’une virgule, puis de l’assembly dans lequel réside le type. Vous pouvez également spécifier la version de l’assembly, la culture et le jeton de clé publique.

Voici un exemple de définition de votre propre fabrique de connexion par défaut :

<entityFramework>
  <defaultConnectionFactory type="MyNamespace.MyCustomFactory, MyAssembly"/>
</entityFramework>

L’exemple ci-dessus nécessite que la fabrique personnalisée dispose d’un constructeur sans paramètre. Si nécessaire, vous pouvez spécifier des paramètres de constructeur à l’aide de l’élément paramètres.

Par exemple, SqlCeConnectionFactory, qui est inclus dans Entity Framework, vous oblige à fournir un nom invariant de fournisseur au constructeur. Le nom invariant du fournisseur identifie la version de SQL Compact que vous souhaitez utiliser. La configuration suivante entraîne l’utilisation par défaut des contextes de SQL Compact version 4.0.

<entityFramework>
  <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlCeConnectionFactory, EntityFramework">
    <parameters>
      <parameter value="System.Data.SqlServerCe.4.0" />
    </parameters>
  </defaultConnectionFactory>
</entityFramework>

Si vous ne définissez pas de fabrique de connexion par défaut, Code First utilise SqlConnectionFactory, pointant vers .\SQLEXPRESS. SqlConnectionFactory a également un constructeur qui vous permet de remplacer des parties de la chaîne de connexion. Si vous souhaitez utiliser une instance SQL Server autre que .\SQLEXPRESS vous pouvez utiliser ce constructeur pour définir le serveur.

La configuration suivante entraîne l’utilisation de Code First MyDatabaseServer pour les contextes qui n’ont pas de chaîne de connexion explicite définie.

<entityFramework>
  <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
    <parameters>
      <parameter value="Data Source=MyDatabaseServer; Integrated Security=True; MultipleActiveResultSets=True" />
    </parameters>
  </defaultConnectionFactory>
</entityFramework>

Par défaut, il est supposé que les arguments de constructeur sont de type chaîne. Vous pouvez utiliser l’attribut de type pour modifier ce paramètre.

<parameter value="2" type="System.Int32" />

Initialiseurs de base de données

Les initialiseurs de base de données sont configurés par contexte. Ils peuvent être définis dans le fichier de configuration à l’aide de l’élément contexte. Cet élément utilise le nom qualifié de l’assembly pour identifier le contexte configuré.

Par défaut, les contextes Code First sont configurés pour utiliser l’initialiseur CreateDatabaseIfNotExists. Il existe un attribut disableDatabaseInitialization sur l’élément de contexte qui peut être utilisé pour désactiver l’initialisation de la base de données.

Par exemple, la configuration suivante désactive l’initialisation de base de données pour le contexte Blogs.BlogContext défini dans MyAssembly.dll.

<contexts>
  <context type=" Blogging.BlogContext, MyAssembly" disableDatabaseInitialization="true" />
</contexts>

Vous pouvez utiliser l’élément databaseInitializer pour définir un initialiseur personnalisé.

<contexts>
  <context type=" Blogging.BlogContext, MyAssembly">
    <databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly" />
  </context>
</contexts>

Les paramètres du constructeur utilisent la même syntaxe que les fabriques de connexion par défaut.

<contexts>
  <context type=" Blogging.BlogContext, MyAssembly">
    <databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly">
      <parameters>
        <parameter value="MyConstructorParameter" />
      </parameters>
    </databaseInitializer>
  </context>
</contexts>

Vous pouvez configurer l’un des initialiseurs de base de données génériques inclus dans Entity Framework. Le type attribut utilise le format .NET Framework pour les types génériques.

Par exemple, si vous utilisez Code First Migrations, vous pouvez configurer la base de données pour qu’elle soit migrée automatiquement à l’aide de l’initialiseur MigrateDatabaseToLatestVersion<TContext, TMigrationsConfiguration>.

<contexts>
  <context type="Blogging.BlogContext, MyAssembly">
    <databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[Blogging.BlogContext, MyAssembly], [Blogging.Migrations.Configuration, MyAssembly]], EntityFramework" />
  </context>
</contexts>