Das Entity Framework 6-Anbietermodell

Das Entity Framework-Anbietermodell ermöglicht die Verwendung von Entity Framework mit verschiedenen Datenbankservertypen. Beispielsweise kann ein Anbieter angeschlossen werden, damit EF für Microsoft SQL Server verwendet werden kann, während ein anderer Anbieter angeschlossen werden kann, damit EF für Microsoft SQL Server Compact Edition verwendet werden kann. Die Anbieter für EF6, die wir kennen, finden Sie auf der Seite Entity Framework-Anbieter.

Bestimmte Änderungen in der Art wie EF mit Anbietern interagiert waren erforderlich, damit EF unter einer Open Source-Lizenz veröffentlicht werden kann. Diese Änderungen erfordern die Neuerstellung von EF-Anbietern gegen die EF6-Assemblys zusammen mit neuen Mechanismen für die Registrierung des Anbieters.

Neuerstellung

Mit EF6 wird der Kerncode, der zuvor Teil von .NET Framework war, nun als Out-of-Band-Assemblys (OOB) ausgeliefert. Details zum Erstellen von Anwendungen mit EF6 finden Sie auf der Seite Aktualisieren von Anwendungen für EF6. Anbieter müssen auch mithilfe dieser Anweisungen neu erstellt werden.

Übersicht über Anbietertypen

Ein EF-Anbieter ist in Wirklichkeit eine Sammlung von anbieterspezifischen Diensten, die von CLR-Typen definiert werden, die diese Dienste erweitern (für eine Basisklasse) oder implementieren (für eine Schnittstelle). Zwei dieser Dienste sind grundlegend und erforderlich, damit EF überhaupt funktionieren kann. Andere sind optional und müssen nur implementiert werden, wenn bestimmte Funktionen erforderlich sind und/oder die Standardimplementierungen dieser Dienste für den jeweiligen Datenbankserver nicht funktionieren.

Grundlegende Anbietertypen

DbProviderFactory

EF ist abhängig davon, dass ein von System.Data.Common.DbProviderFactory abgeleiteter Typ für den gesamten Datenbankzugriff auf niedriger Ebene ausgeführt wird. DbProviderFactory ist nicht tatsächlich Teil von EF, sondern eine Klasse im .NET Framework, die einen Einstiegspunkt für ADO.NET Anbieter bietet, was von EF, anderen O/RMs oder direkt von einer Anwendung verwendet werden kann, um Instanzen von Verbindungen, Befehlen, Parametern und anderen ADO.NET Abstraktionen auf agnostische Weise abzurufen. Weitere Informationen zu DbProviderFactory finden Sie in der MSDN-Dokumentation für ADO.NET.

DbProviderServices

EF ist abhängig davon, dass ein von DbProviderServices abgeleiteter Typ für die Bereitstellung zusätzlicher Funktionen benötigt wird, die EF über die bereits vom ADO.NET-Anbieter hinaus bereitgestellte Funktionalität benötigt. In älteren Versionen von EF war die DbProviderServices-Klasse Teil von .NET Framework und wurde im System.Data.Common-Namespace gefunden. Ab EF6 ist diese Klasse jetzt Teil von EntityFramework.dll und befindet sich im System.Data.Entity.Core.Common-Namespace.

Weitere Details zur grundlegenden Funktionalität einer DbProviderServices-Implementierung finden Sie auf MSDN. Beachten Sie jedoch, dass zu diesem Zeitpunkt die Informationen für EF6 nicht aktualisiert werden, obwohl die meisten Konzepte noch gültig sind. Die SQL Server- und SQL Server Compact-Implementierungen von DbProviderServices werden auch in die Open-Source-Codebasis eingecheckt und können als nützliche Verweise für andere Implementierungen dienen.

In älteren Versionen von EF wurde die zu verwendende DbProviderServices-Implementierung direkt von einem ADO.NET-Anbieter abgerufen. Dies wurde durch Umwandlung von DbProviderFactory in IServiceProvider und Aufrufen der GetService-Methode durchgeführt. Dadurch wurde der EF-Anbieter eng mit der DbProviderFactory gekoppelt. Diese Kopplung hat verhindert, dass EF aus .NET Framework verschoben wird und daher wurde diese enge Kopplung aus EF6 entfernt. Eine Implementierung von DbProviderServices wird jetzt direkt in der Konfigurationsdatei der Anwendung oder in der codebasierten Konfiguration registriert, wie in Registrieren von DbProviderServices weiter unten beschrieben.

Weitere Dienste

Zusätzlich zu den oben beschriebenen grundlegenden Diensten gibt es auch viele andere Dienste, die von EF verwendet werden, die entweder immer oder manchmal anbieterspezifisch sind. Standardmäßige anbieterspezifische Implementierungen dieser Dienste können von einer DbProviderServices-Implementierung bereitgestellt werden. Anwendungen können auch die Implementierungen dieser Dienste außer Kraft setzen oder Implementierungen bereitstellen, wenn ein DbProviderServices-Typ keine Standardeinstellung bereitstellt. Dies wird im Abschnitt Auflösen zusätzlicher Dienste weiter unten ausführlicher beschrieben.

Diese zusätzlichen Diensttypen, die ein Anbieter für einen Anbieter von Interesse sein könnten, sind unten aufgeführt. Weitere Details zu jedem dieser Diensttypen finden Sie in der API-Dokumentation.

IDbExecutionStrategy

Dies ist ein optionaler Dienst, der es einem Anbieter ermöglicht, Wiederholungsversuche oder ein anderes Verhalten zu implementieren, wenn Abfragen und Befehle für die Datenbank ausgeführt werden. Wenn keine Implementierung bereitgestellt wird, führt EF einfach die Befehle aus und verteilt alle ausgelösten Ausnahmen. Für SQL Server wird dieser Dienst verwendet, um eine Wiederholungsrichtlinie bereitzustellen, die besonders nützlich ist, wenn sie auf cloudbasierten Datenbankservern wie SQL Azure ausgeführt wird.

IDbConnectionFactory

Bei diesem optionalen Dienst, wird der es einem Anbieter ermöglicht, DbConnection-Objekte nach Konvention zu erstellen, wenn nur ein Datenbankname angegeben wird. Beachten Sie, dass dieser Dienst zwar durch eine DbProviderServices-Implementierung aufgelöst werden kann, die seit EF 4.1 vorhanden ist und aber auch explizit in der Konfigurationsdatei oder im Code festgelegt werden kann. Der Anbieter erhält nur die Möglichkeit, diesen Dienst aufzulösen, wenn er als Standardanbieter registriert wurde (siehe Standardanbieter unten ) und wenn eine Standardverbindungsfactory nicht an anderer Stelle festgelegt wurde.

DbSpatialServices

Dies ist ein optionaler Dienst, der es einem Anbieter ermöglicht, Unterstützung für geografische und geometriebezogene Typen hinzuzufügen. Eine Implementierung dieses Diensts muss bereitgestellt werden, damit eine Anwendung EF mit räumlichen Typen verwenden kann. DbSpatialServices wird auf zwei Arten angefordert. Zunächst werden anbieterspezifische räumliche Dienste mithilfe eines DbProviderInfo-Objekts (das invariantes Namens- und Manifesttoken enthält) als Schlüssel angefordert. Zweitens kann DbSpatialServices ohne Schlüssel angefordert werden. Dies wird verwendet, um den „globalen räumlichen Anbieter“ aufzulösen, der beim Erstellen eigenständiger DbGeography- oder DbGeometry-Typen verwendet wird.

MigrationSQLGenerator

Dies ist ein optionaler Dienst, mit dem EF-Migrationen für die Generierung von SQL verwendet werden können, die beim Erstellen und Ändern von Datenbankschemas nach Code First verwendet wird. Um Migrationen zu unterstützen, ist eine Implementierung erforderlich. Wenn eine Implementierung bereitgestellt wird, wird sie auch verwendet, wenn Datenbanken mithilfe von Datenbankinitialisierern oder der Database.Create-Methode erstellt werden.

Func<DbConnection, Zeichenfolge, HistoryContextFactory>

Dies ist ein optionaler Dienst, der es einem Anbieter ermöglicht, die Zuordnung des HistoryContext zu der Tabelle zu konfigurieren, die __MigrationHistory von EF-Migrationen verwendet wird. Der HistoryContext ist ein Code First DbContext und kann mithilfe der normalen Fluent-API konfiguriert werden, um Elemente wie den Namen der Tabelle und die Spaltenzuordnungsspezifikationen zu ändern. Die Standardimplementierung dieses Diensts, der von EF für alle Anbieter zurückgegeben wird, kann für einen bestimmten Datenbankserver funktionieren, wenn alle Standardtabellen- und Spaltenzuordnungen von diesem Anbieter unterstützt werden. In diesem Fall muss der Anbieter keine Implementierung dieses Dienstes bereitstellen.

IDbProviderFactoryResolver

Dies ist ein optionaler Dienst zum Abrufen der richtigen DbProviderFactory aus einem bestimmten DbConnection-Objekt. Die Standardimplementierung dieses Dienstes, der von EF für alle Anbieter zurückgegeben wird, soll für alle Anbieter funktionieren. Wenn sie jedoch auf .NET 4 ausgeführt wird, ist die DbProviderFactory aus einer ihrer DbConnections nicht öffentlich zugänglich. Daher verwendet EF einige Heuristiken, um die registrierten Anbieter zu durchsuchen, um eine Übereinstimmung zu finden. Es ist möglich, dass für einige Anbieter diese Heuristiken fehlschlagen und in solchen Situationen sollte der Anbieter eine neue Implementierung bereitstellen.

Registrieren von DbProviderServices

Die zu verwendende DbProviderServices-Implementierung kann entweder in der Konfigurationsdatei der Anwendung (app.config oder web.config) oder mithilfe der codebasierten Konfiguration registriert werden. In beiden Fällen verwendet die Registrierung den „invarianten Namen“ des Anbieters als Schlüssel. Auf diese Weise können mehrere Anbieter in einer einzigen Anwendung registriert und verwendet werden. Der für EF-Registrierungen verwendete invariante Name entspricht dem invarianten Namen, der für ADO.NET Anbieterregistrierung und Verbindungszeichenfolgen verwendet wird. Zum Beispiel wird für SQL Server der invarianten Name „System.Data.SqlClient“ verwendet.

Registrierung über die Konfigurationsdatei

Der zu verwendende DbProviderServices-Typ wird als Anbieterelement in der Anbieterliste des EntityFramework-Abschnitts der Konfigurationsdatei der Anwendung registriert. Beispiel:

<entityFramework>
  <providers>
    <provider invariantName="My.Invariant.Name" type="MyProvider.MyProviderServices, MyAssembly" />
  </providers>
</entityFramework>

Die Typzeichenfolge muss der assemblyqualifizierte Typname der zu verwendenden DbProviderServices-Implementierung sein.

Codebasierte Registrierung

Ab EF6-Anbietern können sie auch mit Code registriert werden. Dadurch kann ein EF-Anbieter ohne Änderung an der Konfigurationsdatei der Anwendung verwendet werden. Um codebasierte Konfiguration zu verwenden, sollte eine Anwendung eine DbConfiguration-Klasse, wie in der codebasierten Konfigurationsdokumentation beschrieben, erstellen. Der Konstruktor der DbConfiguration-Klasse sollte dann SetProviderServices aufrufen, um den EF-Anbieter zu registrieren. Beispiel:

public class MyConfiguration : DbConfiguration
{
    public MyConfiguration()
    {
        SetProviderServices("My.New.Provider", new MyProviderServices());
    }
}

Auflösen zusätzlicher Dienste

Wie bereits in der Anbietertypenübersicht erwähnt, kann eine DbProviderServices-Klasse auch verwendet werden, um zusätzliche Dienste aufzulösen. Dies ist möglich, da DbProviderServices IDbDependencyResolver implementiert und jeder registrierte DbProviderServices-Typ als „Standardlöser“ hinzugefügt wird. Der IDbDependencyResolver-Mechanismus wird unter Abhängigkeitsauflösung ausführlicher beschrieben. Es ist jedoch nicht notwendig, alle Konzepte in dieser Spezifikation zu verstehen, um zusätzliche Dienste in einem Anbieter aufzulösen.

Die gängigste Methode für einen Anbieter zum Auflösen zusätzlicher Dienste ist das Aufrufen von DbProviderServices.AddDependencyResolver für jeden Dienst im Konstruktor der DbProviderServices-Klasse. Zum Beispiel weist SQLProviderServices (der EF-Anbieter für SQL Server) Code auf, welcher der Initialisierung ähnelt:

private SqlProviderServices()
{
    AddDependencyResolver(new SingletonDependencyResolver<IDbConnectionFactory>(
        new SqlConnectionFactory()));

    AddDependencyResolver(new ExecutionStrategyResolver<DefaultSqlExecutionStrategy>(
        "System.data.SqlClient", null, () => new DefaultSqlExecutionStrategy()));

    AddDependencyResolver(new SingletonDependencyResolver<Func<MigrationSqlGenerator>>(
        () => new SqlServerMigrationSqlGenerator(), "System.data.SqlClient"));

    AddDependencyResolver(new SingletonDependencyResolver<DbSpatialServices>(
        SqlSpatialServices.Instance,
        k =>
        {
            var asSpatialKey = k as DbProviderInfo;
            return asSpatialKey == null
                || asSpatialKey.ProviderInvariantName == ProviderInvariantName;
        }));
}

Dieser Konstruktor verwendet die folgenden Hilfsklassen:

• SingletonDependencyResolver: Bietet eine einfache Möglichkeit, Singleton-Dienste aufzulösen, d. h. Dienste, für die dieselbe Instanz jedes Mal zurückgegeben wird, wenn GetService aufgerufen wird. Vorübergehende Dienste werden häufig als Singleton-Factory registriert, die bei Bedarf zum Erstellen vorübergehender Instanzen verwendet wird.
• ExecutionStrategyResolver: Ein bestimmter Resolver für die Rückgabe von IExecutionStrategy-Implementierungen.

Anstatt DbProviderServices.AddDependencyResolver zu verwenden, ist es auch möglich, DbProviderServices.GetService außer Kraft zu setzen und zusätzliche Dienste direkt aufzulösen. Diese Methode wird aufgerufen, wenn EF einen Dienst definiert durch einen bestimmten Typ, und in einigen Fällen durch einen bestimmten Schlüssel, benötigt. Die Methode sollte falls möglich den Dienst zurückgeben, oder NULL, um sich von dem zurückzugebenden Dienst abzumelden, und stattdessen eine anderer Klasse erlauben, ihn aufzulösen. Um beispielsweise die Standardverbindungsfactory aufzulösen, könnte der Code in GetService etwa wie folgt aussehen:

public override object GetService(Type type, object key)
{
    if (type == typeof(IDbConnectionFactory))
    {
        return new SqlConnectionFactory();
    }
    return null;
}

Registrierungsauftrag

Wenn mehrere DbProviderServices-Implementierungen in der Konfigurationsdatei einer Anwendung registriert sind, werden sie als sekundäre Resolver in der Reihenfolge hinzugefügt, in der sie aufgeführt werden. Da Resolver immer am Anfang der sekundären Resolverkette hinzugefügt werden, bedeutet dies, dass der Anbieter am Ende der Liste die Möglichkeit erhält, Abhängigkeiten vor den anderen aufzulösen. (Dies kann zunächst ein wenig kontraintuitiv erscheinen, aber es ist sinnvoll, wenn Sie sich vorstellen, jeden Anbieter aus der Liste herauszunehmen und ihn über die vorhandenen Anbieter zu stapeln.)

Diese Sortierung spielt in der Regel keine Rolle, da die meisten Anbieterdienste anbieterspezifisch sind und nach anbieterinvariantem Namen geschlüsselt sind. Für Dienste, die nicht durch den anbieterinvariante Namen oder andere anbieterspezifische Schlüssel schlüsseln, wird der Dienst basierend auf dieser Bestellung aufgelöst. Wenn es beispielsweise nicht explizit an einer anderen Stelle anders festgelegt wird, stammt die Standardverbindungsfactory vom obersten Anbieter in der Kette.

Zusätzliche Konfigurationsdateiregistrierungen

Es ist möglich, einige der oben beschriebenen zusätzlichen Anbieterdienste explizit in der Konfigurationsdatei einer Anwendung zu registrieren. Wenn dies geschieht, wird die Registrierung in der Konfigurationsdatei anstelle von Elementen verwendet, die von der GetService-Methode der DbProviderServices-Implementierung zurückgegeben werden.

Registrieren der Standardverbindungsfactory

Ab EF5 registriert das EntityFramework NuGet-Paket automatisch die SQL Express-Verbindungsfactory oder die LocalDb-Verbindungsfactory in der Konfigurationsdatei.

Beispiel:

<entityFramework>
  <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" >
</entityFramework>

Der Typ ist der assemblyqualifizierte Typname für die Standardverbindungsfactory, die IDbConnectionFactory implementieren muss.

Es wird empfohlen, dass ein Anbieter-NuGet-Paket die Standardverbindungsfactory auf diese Weise bei der Installation festgelegt. Siehe NuGet-Pakete für Anbieter weiter unten.

Zusätzliche EF6-Anbieteränderungen

Änderungen des räumlichen Anbieters

Anbieter, die räumliche Typen unterstützen, müssen nun einige zusätzliche Methoden für Klassen implementieren, die von DbSpatialDataReader abgeleitet werden:

• public abstract bool IsGeographyColumn(int ordinal)
• public abstract bool IsGeometryColumn(int ordinal)

Es gibt auch neue asynchrone Versionen vorhandener Methoden, die als Standardimplementierungsdelegat der synchronen Methoden außer Kraft gesetzt werden sollten und daher nicht asynchron ausgeführt werden:

• public virtual Task<DbGeography> GetGeographyAsync(int ordinal, CancellationToken cancellationToken)
• public virtual Task<DbGeometry> GetGeometryAsync(int ordinal, CancellationToken cancellationToken)

Native Unterstützung für Enumerable.Contains

EF6 führt einen neuen Ausdruckstyp ein, nämlich DbInExpression, der hinzugefügt wurde, um Leistungsprobleme bei der Verwendung von Enumerable.Contains in LINQ-Abfragen zu beheben. Die DbProviderManifest-Klasse verfügt über eine neue virtuelle Methode, SupportsInExpression, die von EF aufgerufen wird, um zu ermitteln, ob ein Anbieter den neuen Ausdruckstyp verarbeitet. Zur besseren Kompatibilität mit vorhandenen Anbieterimplementierungen gibt die Methode falsch zurück. Um von dieser Verbesserung zu profitieren, kann ein EF6-Anbieter Code hinzufügen, um DbInExpression zu verarbeiten und SupportsInExpression außer Kraft zu setzen, um wahr zurückzugeben. Eine Instanz von DbInExpression kann durch Aufrufen der DbExpressionBuilder.In-Methode erstellt werden. Eine DbInExpression-Instanz besteht aus einem DbExpression, der normalerweise eine Tabellenspalte darstellt, und einer Liste von DbConstantExpression, die auf eine Übereinstimmung getestet werden soll.

NuGet-Pakete für Anbieter

Eine Möglichkeit, einen EF6-Anbieter verfügbar zu machen, besteht darin, ihn als NuGet-Paket freizugeben. Die Verwendung eines NuGet-Pakets hat die folgenden Vorteile:

• Es ist einfach, NuGet zu verwenden, um die Anbieterregistrierung zur Konfigurationsdatei der Anwendung hinzuzufügen
• Zusätzliche Änderungen können an der Konfigurationsdatei vorgenommen werden, um die Standardverbindungsfactory festzulegen, sodass Verbindungen, die durch die Konvention hergestellt werden, den registrierten Anbieter verwenden
• NuGet behandelt das Hinzufügen von Bindungsumleitungen, damit der EF6-Anbieter auch nach der Veröffentlichung eines neuen EF-Pakets weiterhin funktioniert

Ein Beispiel hierfür ist das EntityFramework.SqlServerCompact-Paket, das in der Open-Source-Codebasis enthalten ist. Dieses Paket bietet eine gute Vorlage zum Erstellen von NuGet-Paketen des EF-Anbieters.

PowerShell-Befehle

Wenn das EntityFramework NuGet-Paket installiert ist, registriert es ein PowerShell-Modul, das zwei Befehle enthält, die für Anbieterpakete sehr nützlich sind:

• Add-EFProvider fügt eine neue Entität für den Anbieter in der Konfigurationsdatei des Zielprojekts hinzu und stellt sicher, dass er am Ende der Liste der registrierten Anbieter steht.
• Add-EFDefaultConnectionFactory fügt die defaultConnectionFactory-Registrierung in der Konfigurationsdatei des Zielprojekts hinzu oder aktualisiert sie.

Beide Befehle kümmern sich um das Hinzufügen eines EntityFramework-Abschnitts zur Konfigurationsdatei und bei Bedarf dem Hinzufügen einer Anbietersammlung.

Es ist vorgesehen, dass diese Befehle über das NuGet-Skript install.ps1 aufgerufen werden. Zum Beispiel sieht install.ps1 für den SQL Compact-Anbieter wie folgt aus:

param($installPath, $toolsPath, $package, $project)
Add-EFDefaultConnectionFactory $project 'System.Data.Entity.Infrastructure.SqlCeConnectionFactory, EntityFramework' -ConstructorArguments 'System.Data.SqlServerCe.4.0'
Add-EFProvider $project 'System.Data.SqlServerCe.4.0' 'System.Data.Entity.SqlServerCompact.SqlCeProviderServices, EntityFramework.SqlServerCompact'</pre>

Weitere Informationen zu diesen Befehlen erhalten Sie mithilfe von get-help im Paket-Manager-Konsolenfenster.

Umbruchanbieter

Ein Umbruchanbieter ist ein EF- und/oder ADO.NET-Anbieter, der einen vorhandenen Anbieter umschließt, um ihn mit anderen Funktionen wie Profilerstellungs- oder Ablaufverfolgungsfunktionen zu erweitern. Umbruchanbieter können auf die normale Art registriert werden, aber es ist oft einfacher, die Umbruchanbieter während der Laufzeit durch Unterbrechen der Lösung von anbieterverwandten Diensten einzurichten. Das statische Ereignis OnLockingConfiguration für die DbConfiguration-Klasse kann hierzu verwendet werden.

OnLockingConfiguration wird aufgerufen, nachdem EF ermittelt hat, von wo aus alle EF-Konfigurationen für die App-Domäne abgerufen werden, aber bevor sie zur Verwendung gesperrt wird. Beim Starten der App (bevor EF verwendet wird) sollte die App einen Ereignishandler für dieses Ereignis registrieren. (Wir erwägen das Hinzufügen der Unterstützung für die Registrierung dieses Handlers in der Konfigurationsdatei, dies passiert jedoch aktuell noch nicht.) Der Ereignishandler sollte dann für jeden Dienst, der umschlossen werden muss, einen Aufruf an ReplaceService durchführen.

Um beispielsweise IDbConnectionFactory und DbProviderService zu umschließen, sollte ein Handler wie folgt registriert werden:

DbConfiguration.OnLockingConfiguration +=
    (_, a) =>
    {
        a.ReplaceService<DbProviderServices>(
            (s, k) => new MyWrappedProviderServices(s));

        a.ReplaceService<IDbConnectionFactory>(
            (s, k) => new MyWrappedConnectionFactory(s));
    };

Der aufgelöste Dienst, der nun zusammen mit dem Schlüssel umschlossen, der zum Auflösen des Diensts verwendet wurde, werden soll, wird an den Handler übergeben. Der Handler kann diesen Dienst dann umschließen und den zurückgegebenen Dienst durch die umschlossene Version ersetzen.

Auflösen einer DbProviderFactory mit EF

DbProviderFactory ist einer der grundlegenden Anbietertypen, die von EF benötigt werden, wie in der Anbietertypenübersicht oben beschrieben. Wie bereits erwähnt, ist es kein EF-Typ, und die Registrierung ist in der Regel nicht Teil der EF-Konfiguration, sondern ist stattdessen die normale ADO.NET Anbieterregistrierung in der Datei machine.config und/oder der Konfigurationsdatei der Anwendung.

Trotzdem verwendet EF bei der Suche nach einer dbProviderFactory weiterhin seinen normalen Abhängigkeitsauflösungsmechanismus. Der Standardlöser verwendet die normale ADO.NET Registrierung in den Konfigurationsdateien und ist daher in der Regel transparent. Aufgrund des normalen Mechanismus zur Auflösung von Abhängigkeiten bedeutet dies jedoch, dass ein IDbDependencyResolver verwendet werden kann, um eine DbProviderFactory aufzulösen, auch wenn die normale ADO.NET Registrierung nicht erfolgt ist.

Das Auflösen von DbProviderFactory hat auf diese Weise mehrere Auswirkungen:

• Eine Anwendung, die codebasierte Konfiguration verwendet, kann Aufrufe in ihrer DbConfiguration-Klasse hinzufügen, um die entsprechende DbProviderFactory zu registrieren. Dies ist besonders nützlich für Anwendungen, die keine dateibasierte Konfiguration verwenden möchten (oder können).
• Der Dienst kann mithilfe von ReplaceService umschlossen oder ersetzt werden, wie unter Wrapping-Anbieter oberhalb beschrieben
• Theoretisch könnte eine DbProviderServices-Implementierung eine DbProviderFactory auflösen.

Wichtig ist zu beachten, dass sie sich nur auf die Suche von DbProviderFactory durch EF auswirken. Anderer Nicht-EF-Code erwarten möglicherweise weiterhin, dass der ADO.NET-Anbieter auf normale Weise registriert wird und schlägt fehl, wenn die Registrierung nicht gefunden wird. Aus diesem Grund ist es in der Regel besser, dass eine DbProviderFactory auf die normale ADO.NET Weise registriert wird.

Verknüpfte Dienste

Wenn EF verwendet wird, um eine DbProviderFactory aufzulösen, sollte sie auch die Dienste IProviderInvariantName und IDbProviderFactoryResolver auflösen.

IProviderInvariantName ist ein Dienst, der verwendet wird, um einen anbieterinvarianten Namen für einen bestimmten Typ von DbProviderFactory zu bestimmen. Die Standardimplementierung dieses Dienstes verwendet die ADO.NET-Anbieterregistrierung. Wenn der ADO.NET-Anbieter nicht auf die normale Weise registriert wird bedeutet es, dass es dann auch erforderlich ist, diesen Dienst aufzulösen, da DbProviderFactory von EF aufgelöst wird. Beachten Sie, dass bei Verwendung der DbConfiguration.SetProviderFactory-Methode automatisch ein Resolver für diesen Dienst hinzugefügt wird.

Wie oben in der Anbietertypenübersicht beschrieben, wird der IDbProviderFactoryResolver verwendet, um die richtige DbProviderFactory aus einem bestimmten DbConnection-Objekt abzurufen. Die Standardimplementierung dieses Diensts, wenn er unter .NET 4 ausgeführt wird, verwendet die ADO.NET-Anbieterregistrierung. Wenn der ADO.NET-Anbieter nicht auf die normale Weise registriert wird bedeutet es, dass es dann auch erforderlich ist, diesen Dienst aufzulösen, da DbProviderFactory von EF aufgelöst wird.