Konfigurationsdateieinstellungen

  • Artikel

Entity Framework ermöglicht Ihnen, eine Reihe von Einstellungen in der Konfigurationsdatei anzugeben. Im Allgemeinen folgt EF einem Prinzip der „Konvention vor Konfiguration“: Alle in diesem Beitrag beschriebenen Einstellungen weisen ein Standardverhalten auf, Sie müssen also nur die Einstellungen ändern, deren Standardwerte Ihre Anforderungen nicht erfüllen.

Eine codebasierte Alternative

Alle diese Einstellungen können auch mit Code angewandt werden. Ab EF6 wurde eine codebasierte Konfiguration eingeführt, die eine zentrale Möglichkeit zum Anwenden der Konfiguration aus dem Code bietet. In Versionen vor EF6 kann die Konfiguration weiterhin aus Code angewandt werden, Sie müssen jedoch verschiedene APIs verwenden, um unterschiedliche Bereiche zu konfigurieren. Mit der Konfigurationsdateioption können diese Einstellungen während der Bereitstellung problemlos geändert werden, ohne den Code zu aktualisieren.

Der Abschnitt „Configuration“ von Entity Framework

Ab EF4.1 können Sie den Datenbankinitialisierer für einen Kontext mithilfe des Abschnitts appSettings der Konfigurationsdatei festlegen. In EF4.3 wurde der benutzerdefinierte Abschnitt entityFramework eingeführt, um die neuen Einstellungen zu behandeln. Entity Framework erkennt weiterhin Datenbankinitialisierer, die mit dem alten Format festgelegt wurden. Es wird jedoch empfohlen, nach Möglichkeit zum neuen Format zu wechseln.

Der Abschnitt entityFramework wurde automatisch der Konfigurationsdatei Ihres Projekts hinzugefügt, als Sie das EntityFramework-NuGet-Paket installiert haben.

<?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>

Verbindungszeichenfolgen

Diese Seite enthält weitere Details dazu, wie Entity Framework die zu verwendende Datenbank bestimmt, einschließlich Verbindungszeichenfolgen in der Konfigurationsdatei.

Verbindungszeichenfolgen werden im connectionStrings-Standardelement verwendet und erfordern keinen Abschnitt entityFramework.

Code First-Modelle verwenden normale ADO.NET-Verbindungszeichenfolgen. Beispiel:

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

EF Designer-Modelle verwenden spezielle EF-Verbindungszeichenfolgen. Beispiel:

<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>

Codebasierter Konfigurationstyp (ab EF6)

Ab EF6 können Sie die DbConfiguration für EF angeben, die für die codebasierte Konfiguration in Ihrer Anwendung verwendet werden soll. In den meisten Fällen müssen Sie diese Einstellung nicht angeben, da EF Ihre DbConfiguration automatisch erkennt. Ausführliche Informationen dazu, wann Sie DbConfiguration in Ihrer Konfigurationsdatei angeben müssen, finden Sie im Abschnitt Verschieben von DbConfiguration unter Codebasierte Konfiguration.

Um einen DbConfiguration-Typ festzulegen, geben Sie den qualifizierten Assemblytypnamen im codeConfigurationType-Element an.

Hinweis

Ein qualifizierter Assemblyname ist der qualifizierte Namespacename, gefolgt von einem Komma und der Assembly, in der sich der Typ befindet. Optional können Sie auch die Assemblyversion, die Kultur und das Token mit öffentlichem Schlüssel angeben.

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

EF-Datenbankanbieter (ab EF6)

Vor EF6 mussten Entity Framework-spezifische Teile eines Datenbankanbieters als Teil des ADO.NET-Kernanbieters einbezogen werden. Ab EF6 werden die EF-spezifischen Teile jetzt separat verwaltet und registriert.

Normalerweise müssen Sie Anbieter nicht selbst registrieren. Dies wird in der Regel vom Anbieter durchgeführt, wenn Sie ihn installieren.

Anbieter werden registriert, indem ein provider-Element unter dem untergeordneten Abschnitt providers des Abschnitts entityFramework eingeschlossen wird. Es gibt zwei erforderliche Attribute für einen Anbietereintrag:

  • invariantName gibt den ADO.NET-Kernanbieter an, auf den dieser EF-Anbieter ausgerichtet ist.
  • type ist der qualifizierte Assemblytypname der EF-Anbieterimplementierung.

Hinweis

Ein qualifizierter Assemblyname ist der qualifizierte Namespacename, gefolgt von einem Komma und der Assembly, in der sich der Typ befindet. Optional können Sie auch die Assemblyversion, die Kultur und das Token mit öffentlichem Schlüssel angeben.

Das folgende Beispiel ist der zum Registrieren des SQL Server-Standardanbieters erstellte Eintrag, wenn Sie Entity Framework installieren.

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

Abfangfunktionen (Interceptors, ab EF6.1)

Ab EF6.1 können Sie in der Konfigurationsdatei Abfangfunktionen registrieren. Abfangfunktionen ermöglichen Ihnen, zusätzliche Logik auszuführen, wenn EF bestimmte Vorgänge ausführt, z. B. Datenbankabfragen, das Öffnen von Verbindungen usw.

Abfangfunktionen werden registriert, indem ein interceptor-Element unter dem untergeordneten Abschnittinterceptors des Abschnitts entityFramework eingeschlossen wird. Die folgende Konfiguration registriert beispielsweise den integrierten DatabaseLogger-Interceptor, der alle Datenbankvorgänge an der Konsole protokolliert.

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

Protokollieren von Datenbankvorgängen in einer Datei (ab EF6.1)

Das Registrieren von Abfangfunktionen über die Konfigurationsdatei ist besonders hilfreich, wenn Sie eine vorhandene Anwendung um eine Protokollierung ergänzen möchten, um ein Problem zu debuggen. DatabaseLogger unterstützt die Protokollierung in einer Datei, indem Sie den Dateinamen als Konstruktorparameter angeben.

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

Standardmäßig wird die Protokolldatei bei jedem Start der App mit einer neuen Datei überschrieben. Um neue Einträge stattdessen in einer bereits vorhandenen Protokolldatei anzufügen, verwenden Sie z. B. Folgendes:

<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>

Weitere Informationen zu DatabaseLogger und zum Registrieren von Abfangfunktionen finden Sie im Blogbeitrag EF6.1: Aktivieren der Protokollierung ohne erneutes Kompilieren.

Code First-Standardverbindungsfactory

Im Abschnitt „configuration“ können Sie eine Standardverbindungsfactory angeben, die bei Code First verwendet werden soll, um eine Datenbank zu suchen, die für einen Kontext verwendet werden soll. Die Standardverbindungsfactory wird nur verwendet, wenn der Konfigurationsdatei für einen Kontext keine Verbindungszeichenfolge hinzugefügt wurde.

Wenn Sie das EF-NuGet-Paket installiert haben, wurde bereits eine Standardverbindungsfactory registriert, die auf SQL Express oder LocalDB verweist, je nachdem, was installiert ist.

Um eine Verbindungsfactory festzulegen, geben Sie den qualifizierten Assemblytypnamen im defaultConnectionFactory-Element an.

Hinweis

Ein qualifizierter Assemblyname ist der qualifizierte Namespacename, gefolgt von einem Komma und der Assembly, in der sich der Typ befindet. Optional können Sie auch die Assemblyversion, die Kultur und das Token mit öffentlichem Schlüssel angeben.

Das folgende Beispiel veranschaulicht das Festlegen einer eigenen Standardverbindungsfactory:

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

Im obigen Beispiel muss die benutzerdefinierte Factory einen parameterlosen Konstruktor aufweisen. Bei Bedarf können Sie Konstruktorparameter mithilfe des parameters-Elements angeben.

Beispielsweise erfordert die SqlCeConnectionFactory, die in Entity Framework enthalten ist, dass Sie einen invarianten Anbieternamen an den Konstruktor übergeben. Der invariante Anbietername gibt die Version von SQL Compact an, die Sie verwenden möchten. Die folgende Konfiguration bewirkt, dass Kontexte standardmäßig Version 4.0 von SQL Compact verwenden.

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

Wenn Sie keine Standardverbindungsfactory festlegen, wird bei Code First die SqlConnectionFactory verwendet, die auf .\SQLEXPRESS verweist. SqlConnectionFactory verfügt auch über einen Konstruktor, mit dem Sie Teile der Verbindungszeichenfolge überschreiben können. Wenn Sie eine andere SQL Server-Instanz als .\SQLEXPRESS verwenden möchten, können Sie diesen Konstruktor verwenden, um den Server festzulegen.

Die folgende Konfiguration bewirkt, dass bei Code First MyDatabaseServer für Kontexte verwendet wird, für die keine explizite Verbindungszeichenfolge festgelegt wurde.

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

Standardmäßig wird davon ausgegangen, dass Konstruktorargumente vom Typ „string“ sind. Sie können das type-Attribut verwenden, um dies zu ändern.

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

Datenbankinitialisierer

Datenbankinitialisierer werden jeweils für einen Kontext konfiguriert. Sie können in der Konfigurationsdatei mithilfe des context-Elements festgelegt werden. Dieses Element verwendet den qualifizierten Assemblynamen, um den konfigurierten Kontext zu ermitteln.

Standardmäßig sind Code First-Kontexte so konfiguriert, dass der CreateDatabaseIfNotExists-Initialisierer verwendet wird. Es gibt ein disableDatabaseInitialization-Attribut für das context-Element, das zum Deaktivieren der Datenbankinitialisierung verwendet werden kann.

Die folgende Konfiguration deaktiviert beispielsweise die Datenbankinitialisierung für den in „MyAssembly.dll“ definierten Blogging.BlogContext-Kontext.

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

Sie können das databaseInitializer-Element verwenden, um einen benutzerdefinierten Initialisierer festzulegen.

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

Bei Konstruktorparameter wird dieselbe Syntax wie bei Standardverbindungsfactorys verwendet.

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

Sie können einen der generischen Datenbankinitialisierer konfigurieren, die in Entity Framework enthalten sind. Das type-Attribut verwendet das .NET Framework-Format für generische Typen.

Wenn Sie beispielsweise Code First-Migrationsvorgänge verwenden, können Sie die Datenbank so konfigurieren, dass sie automatisch mithilfe des MigrateDatabaseToLatestVersion<TContext, TMigrationsConfiguration>-Initialisierers migriert wird.

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