Entity Framework 6 공급자 모델

아티클
10/05/2023

Entity Framework 공급자 모델을 사용하면 Entity Framework를 다양한 유형의 데이터베이스 서버와 함께 사용할 수 있습니다. 예를 들어 Microsoft SQL Server 대해 EF를 사용할 수 있도록 한 공급자를 연결하고 다른 공급자를 연결하여 Microsoft SQL Server Compact Edition에 대해 EF를 사용할 수 있습니다. 알고 있는 EF6용 공급자는 Entity Framework 공급자 페이지에서 확인할 수 있습니다.

EF가 오픈 소스 라이선스에 따라 릴리스될 수 있도록 EF가 공급자와 상호 작용하는 방식에 특정 변경이 필요했습니다. 이러한 변경 내용을 사용하려면 공급자 등록을 위한 새로운 메커니즘과 함께 EF6 어셈블리에 대해 EF 공급자를 다시 빌드해야 합니다.

다시 빌드

EF6에서는 이전에 .NET Framework의 일부였던 핵심 코드가 이제 OOB(대역 외) 어셈블리로 제공됩니다. EF6에 대해 애플리케이션을 빌드하는 방법에 대한 자세한 내용은 EF6용 애플리케이션 업데이트 페이지에서 확인할 수 있습니다. 또한 공급자는 이러한 지침을 사용하여 다시 빌드해야 합니다.

공급자 유형 개요

EF 공급자는 실제로 이러한 서비스가 확장(기본 클래스의 경우)되거나 구현(인터페이스의 경우)되는 CLR 형식으로 정의된 공급자별 서비스의 컬렉션입니다. 이러한 서비스 중 두 가지는 EF가 작동하기 위한 기본 사항이며 필수입니다. 다른 기능은 선택 사항이며 특정 기능이 필요하거나 이러한 서비스의 기본 구현이 대상으로 지정된 특정 데이터베이스 서버에 대해 작동하지 않는 경우에만 구현해야 합니다.

기본 공급자 유형

DbProviderFactory

EF는 모든 하위 수준 데이터베이스 액세스를 수행하기 위해 System.Data.Common.DbProviderFactory에서 파생된 형식을 갖는 것에 따라 달라집니다. DbProviderFactory는 실제로 EF의 일부가 아니지만 EF, 기타 O/RM 또는 애플리케이션에서 직접 사용하여 공급자에 구애받지 않는 방식으로 연결, 명령, 매개 변수 및 기타 ADO.NET 추상화의 인스턴스를 가져오는 데 사용할 수 있는 ADO.NET 공급자에 대한 진입점을 제공하는 .NET Framework의 클래스입니다. DbProviderFactory에 대한 자세한 내용은 ADO.NET에 대한 MSDN 설명서에서 확인할 수 있습니다.

DbProviderServices

EF는 ADO.NET 공급자가 이미 제공한 기능을 기반으로 EF에 필요한 추가 기능을 제공하기 위해 DbProviderServices에서 파생된 형식을 갖는 것에 따라 달라집니다. 이전 버전의 EF에서 DbProviderServices 클래스는 .NET Framework 일부였으며, 이는 System.Data.Common 네임스페이스에서 확인할 수 있습니다. EF6부터 이제 이 클래스는 EntityFramework.dll의 일부이며, 이는 System.Data.Entity.Core.Common 네임스페이스에서 확인할 수 있습니다.

DbProviderServices 구현의 기본 기능에 대한 자세한 내용은 MSDN에서 확인할 수 있습니다. 그러나 대부분의 개념이 여전히 유효하더라도 이 정보를 작성하는 시점에는 EF6에 대해 업데이트되지 않았습니다. 또한 DbProviderServices의 SQL Server 및 SQL Server Compact 구현이 오픈 소스 코드베이스에 체크 인되고 다른 구현에 유용한 참조로 사용될 수 있습니다.

이전 버전의 EF에서는 사용할 DbProviderServices 구현을 ADO.NET 공급자에서 직접 가져옵니다. 이 작업은 DbProviderFactory를 IServiceProvider로 캐스팅하고 GetService 메서드를 호출하여 수행되었습니다. 이는 EF 공급자를 DbProviderFactory에 긴밀하게 결합했습니다. 이 결합은 EF가 .NET Framework 밖으로 이동하지 못하도록 차단하므로 EF6의 경우 이 긴밀한 결합이 제거되었으며, 이제 DbProviderServices 구현은 아래의 DbProviderServices 등록 섹션에 설명된 대로 애플리케이션 구성 파일 또는 코드 기반 구성에 직접 등록됩니다.

추가 서비스

위에서 설명한 기본 서비스 외에도 항상 또는 경우에 따라 공급자별 EF에서 사용되는 다른 많은 서비스도 있습니다. 이러한 서비스의 기본 공급자별 구현은 DbProviderServices 구현에서 제공할 수 있습니다. 애플리케이션은 이러한 서비스의 구현을 재정의하거나 DbProviderServices 형식이 기본값을 제공하지 않는 경우 구현을 제공할 수도 있습니다. 이에 대해서는 아래의 추가 서비스 해결 섹션에 자세히 설명되어 있습니다.

공급자가 공급자에게 관심을 가질 수 있는 추가 서비스 유형은 다음과 같습니다. 이러한 각 서비스 유형에 대한 자세한 내용은 API 설명서에서 확인할 수 있습니다.

IDbExecutionStrategy

데이터베이스에 대해 쿼리 및 명령이 실행될 때 공급자가 다시 시도 또는 기타 동작을 구현할 수 있는 선택적 서비스입니다. 구현이 제공되지 않는 경우 EF는 단순히 명령을 실행하고 throw된 예외를 전파합니다. SQL Server의 경우 이 서비스는 SQL Azure와 같은 클라우드 기반 데이터베이스 서버에서 실행할 때 특히 유용한 재시도 정책을 제공하는 데 사용됩니다.

IDbConnectionFactory

데이터베이스 이름만 지정된 경우 공급자가 규칙에 따라 DbConnection 개체를 만들 수 있는 선택적 서비스입니다. 이 서비스는 DbProviderServices 구현으로 확인할 수 있지만 EF 4.1 이후 존재했으며 구성 파일 또는 코드에서 명시적으로 설정할 수도 있습니다. 공급자는 기본 공급자로 등록되어 있고(아래 기본 공급자 참조) 기본 연결 팩터리를 다른 곳에 설정하지 않은 경우에만 이 서비스를 해결할 수 있습니다.

DbSpatialServices

공급자가 지리 및 기하 도형 공간 형식에 대한 지원을 추가할 수 있는 선택적 서비스입니다. 애플리케이션이 공간 형식과 함께 EF를 사용하려면 이 서비스의 구현을 제공해야 합니다. DbSptialServices는 두 가지 방법으로 요청됩니다. 첫 번째, DbProviderInfo 개체(고정 이름 및 매니페스트 토큰 포함)를 키로 사용하여 공급자별 공간 서비스를 요청합니다. 두 번째, 키 없이 DbSpatialServices를 요청할 수 있습니다. 독립 실행형 DbGeography 또는 DbGeometry 형식을 만들 때 사용되는 "전역 공간 공급자"를 확인하는 데 사용됩니다.

MigrationSqlGenerator

Code First에서 데이터베이스 스키마를 만들고 수정하는 데 사용되는 SQL 생성에 EF 마이그레이션을 사용할 수 있는 선택적 서비스입니다. 마이그레이션을 지원하려면 구현이 필요합니다. 구현이 제공되면 데이터베이스 이니셜라이저 또는 Database.Create 메서드를 사용하여 데이터베이스를 만들 때도 사용됩니다.

Func<DbConnection, 문자열, HistoryContextFactory>

공급자가 EF 마이그레이션에서 사용하는 __MigrationHistory 테이블에 대한 HistoryContext 매핑을 구성할 수 있는 선택적 서비스입니다. HistoryContext는 Code First DbContext이며 일반 흐름 API를 사용하여 테이블 이름 및 열 매핑 사양과 같은 항목을 변경하도록 구성할 수 있습니다. 모든 기본 테이블 및 열 매핑이 해당 공급자에서 지원되는 경우 모든 공급자에 대해 EF에서 반환하는 이 서비스의 기본 구현은 지정된 데이터베이스 서버에 대해 작동할 수 있습니다. 이러한 경우 공급자는 이 서비스의 구현을 제공할 필요가 없습니다.

IDbProviderFactoryResolver

지정된 DbConnection 개체에서 올바른 DbProviderFactory를 가져오기 위한 선택적 서비스입니다. 모든 공급자에 대해 EF에서 반환하는 이 서비스의 기본 구현은 모든 공급자에 대해 작동합니다. 그러나 .NET 4에서 실행하면 DbProviderFactory가 DbConnections인 경우 하나의 공급자에서 공개적으로 액세스할 수 없습니다. 따라서 EF는 일부 추론을 통해 등록된 공급자를 검색하여 일치 항목을 찾습니다. 일부 공급자의 경우 이러한 추론이 실패하고 이러한 상황에서 공급자가 새 구현을 제공해야 할 수 있습니다.

DbProviderServices 등록

사용할 DbProviderServices 구현은 애플리케이션 구성 파일(app.config 또는 web.config) 또는 코드 기반 구성을 사용하여 등록할 수 있습니다. 두 경우 모두 등록은 공급자의 "고정 이름"을 키로 사용합니다. 그러면 여러 공급자를 등록하고 단일 애플리케이션에서 사용할 수 있습니다. EF 등록에 사용되는 고정 이름은 ADO.NET 공급자 등록 및 연결 문자열에 사용되는 고정 이름과 동일합니다. 예를 들어 SQL Server의 경우 고정 이름 "System.Data.SqlClient"가 사용됩니다.

구성 파일 등록

사용할 DbProviderServices 형식은 애플리케이션 구성 파일의 entityFramework 섹션 내 공급자 목록에서 공급자 요소로 등록됩니다. 예시:

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

형식 문자열은 사용할 DbProviderServices 구현의 정규화된 어셈블리 형식 이름이어야 합니다.

코드 기반 등록

EF6부터는 공급자가 코드를 사용하여 등록할 수도 있습니다. 그러면 애플리케이션의 구성 파일을 변경하지 않고 EF 공급자를 사용할 수 있습니다. 코드 기반 구성을 사용하려면 애플리케이션이 코드 기반 구성 설명서에 설명된 대로 DbConfiguration 클래스를 만들어야 합니다. DbConfiguration 클래스의 생성자는 SetProviderServices를 호출하여 EF 공급자를 등록해야 합니다. 예시:

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

추가 서비스 해결

공급자 유형 개요 섹션에서 위에서 설명한 것처럼 DbProviderServices 클래스를 사용하여 추가 서비스를 해결할 수도 있습니다. 이는 DbProviderServices가 IDbDependencyResolver를 구현하고 등록된 각 DbProviderServices 형식이 "기본 확인자"로 추가되기 때문에 가능합니다. IDbDpendencyResolver 메커니즘은 종속성 확인에 자세히 설명되어 있습니다. 그러나 공급자의 추가 서비스를 해결하기 위해 이 사양의 모든 개념을 이해할 필요는 없습니다.

공급자가 추가 서비스를 해결하는 가장 일반적인 방법은 DbProviderServices 클래스의 생성자에서 각 서비스에 대해 DbProviderServices.AddDependencyResolver를 호출하는 것입니다. 예를 들어 SqlProviderServices(SQL Server에 대한 EF 공급자)에는 초기화를 위해 다음과 유사한 코드가 있습니다.

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;
        }));
}

이 생성자는 다음의 도우미 클래스를 사용합니다.

SingletonDependencyResolver: 단일 서비스를 해결하는 간단한 방법, 즉 GetService가 호출될 때마다 동일한 인스턴스가 반환되는 서비스를 제공합니다. 임시 서비스는 요청 시 일시적인 인스턴스를 만드는 데 사용되는 싱글톤 팩터리로 등록되는 경우가 많습니다.
ExecutionStrategyResolver: IExecutionStrategy 구현 반환과 관련된 확인자입니다.

DbProviderServices.AddDependencyResolver를 사용하는 대신 DbProviderServices.GetService를 재정의하고 추가 서비스를 직접 해결할 수도 있습니다. 이 메서드는 EF에 특정 형식으로 정의된 서비스가 필요하면 경우에 따라 지정된 키에 대해 호출됩니다. 가능한 경우 메서드는 서비스를 반환하거나 null을 반환하여 서비스 반환을 옵트아웃하고 대신 다른 클래스가 서비스를 해결하도록 허용해야 합니다. 예를 들어 기본 연결 팩터리를 해결하기 위해 GetService의 코드가 다음과 같이 표시될 수 있습니다.

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

등록 순서

여러 DbProviderServices 구현이 애플리케이션 구성 파일에 등록되면 나열된 순서대로 보조 확인자로 추가됩니다. 확인자는 항상 보조 확인자 체인의 맨 위에 추가되므로 목록의 끝에 있는 공급자는 종속성을 다른 공급자보다 먼저 확인할 기회를 얻게 됩니다. (처음에는 약간 직관적이지 않은 것처럼 보일 수 있지만, 각 공급자를 목록에서 꺼내 기존 공급자 위에 쌓아 두는 것이 합리적입니다.)

대부분의 공급자 서비스는 공급자별 서비스이며 공급자 고정 이름으로 키가 지정되므로 이러한 순서는 일반적으로 중요하지 않습니다. 그러나 공급자 고정 이름 또는 다른 공급자별 키로 키가 지정되지 않은 서비스의 경우 이러한 순서에 따라 서비스가 해결됩니다. 예를 들어 다른 위치에서 명시적으로 다르게 설정되지 않은 경우 기본 연결 팩터리는 체인의 최상위 공급자에서 가져옵니다.

추가 구성 파일 등록

위에서 설명한 일부 추가 공급자 서비스를 애플리케이션 구성 파일에 직접 명시적으로 등록할 수 있습니다. 이 작업이 완료되면 구성 파일의 등록은 DbProviderServices 구현의 GetService 메서드에서 반환된 항목 대신 사용됩니다.

기본 연결 팩터리 등록

EF5부터 EntityFramework NuGet 패키지는 구성 파일에 SQL Express 연결 팩터리 또는 LocalDb 연결 팩터리를 자동으로 등록합니다.

예시:

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

형식은 IDbConnectionFactory를 구현해야 하는 기본 연결 팩터리의 정규화된 어셈블리 형식 이름입니다.

공급자 NuGet 패키지가 설치될 때 이러한 방식으로 기본 연결 팩터리를 설정하는 것이 좋습니다. 아래의 공급자에 대한 NuGet 패키지를 참조하세요.

추가 EF6 공급자 변경

공간 공급자 변경

이제 공간 형식을 지원하는 공급자는 DbSpatialDataReader에서 파생된 클래스에 몇 가지 추가 메서드를 구현해야 합니다.

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

또한 기존 메서드의 새로운 비동기 버전도 있으며, 이는 기본 구현이 비동기 메서드에 위임되어 비동기적으로 실행되지 않아 재정의하는 것이 좋습니다.

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

Enumerable.Contains에 대한 네이티브 지원

EF6에는 LINQ 쿼리에서 Enumerable.Contains 사용과 관련된 성능 문제를 해결하기 위해 추가된 새로운 식 형식 DbInExpression이 도입되었습니다. DbProviderManifest 클래스에는 공급자가 새로운 식 형식을 처리하는지 여부를 확인하기 위해 EF에서 호출하는 새로운 가상 메서드인 SupportsInExpression이 있습니다. 기존 공급자 구현과의 호환성을 위해 메서드는 false를 반환합니다. 이러한 향상된 기능을 활용하기 위해 EF6 공급자는 DbInExpression을 처리하는 코드를 추가하고 SupportsInExpression을 재정의하여 true를 반환할 수 있습니다. DbInExpression 인스턴스는 DbExpressionBuilder.In 메서드를 호출하여 만들 수 있습니다. DbInExpression 인스턴스는 일반적으로 테이블 열을 나타내는 DbExpression 및 일치를 테스트할 DbConstantExpression 목록으로 구성됩니다.

공급자용 NuGet 패키지

EF6 공급자를 사용할 수 있는 한 가지 방법은 NuGet 패키지로 릴리스하는 것입니다. NuGet 패키지를 사용하면 다음과 같은 이점이 있습니다.

NuGet을 사용하여 애플리케이션 구성 파일에 공급자 등록을 쉽게 추가할 수 있습니다.
규칙에 따라 만든 연결이 등록된 공급자를 사용하도록 기본 연결 팩터리를 설정하기 위해 구성 파일을 추가로 변경할 수 있습니다.
NuGet은 새 EF 패키지가 릴리스된 후에도 EF6 공급자가 계속 작동하도록 바인딩 리디렉션 추가를 처리합니다.

이 예제는 오픈 소스 코드베이스에 포함된 EntityFramework.SqlServerCompact 패키지입니다. 이 패키지는 EF 공급자 NuGet 패키지를 만들기 위한 좋은 템플릿을 제공합니다.

PowerShell 명령

EntityFramework NuGet 패키지가 설치되면 공급자 패키지에 매우 유용한 두 가지 명령이 포함된 PowerShell 모듈을 등록합니다.

Add-EFProvider는 대상 프로젝트의 구성 파일에 공급자에 대한 새 엔터티를 추가하고 해당 엔터티가 등록된 공급자 목록의 끝에 있는지 확인합니다.
Add-EFDefaultConnectionFactory는 대상 프로젝트의 구성 파일에 defaultConnectionFactory 등록을 추가하거나 업데이트합니다.

두 명령 모두 구성 파일에 entityFramework 섹션을 추가하고 필요한 경우 공급자 컬렉션을 추가하는 작업을 수행합니다.

이러한 명령은 install.ps1 NuGet 스크립트에서 호출됩니다. 예를 들어 SQL Compact 공급자에 대한 install.ps1은 다음과 유사합니다.

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>

이러한 명령에 대한 자세한 내용은 패키지 관리자 콘솔 창에서 get-help를 사용하여 얻을 수 있습니다.

래핑 공급자

래핑 공급자는 프로파일링 또는 추적 기능과 같은 다른 기능으로 확장하기 위해 기존 공급자를 래핑하는 EF 및/또는 ADO.NET 공급자입니다. 래핑 공급자는 정상적인 방식으로 등록할 수 있지만 공급자 관련 서비스의 해결을 가로채 런타임에 래핑 공급자를 설정하는 것이 더 편리한 경우가 많습니다. DbConfiguration 클래스의 정적 이벤트 OnLockingConfiguration을 사용하여 이 작업을 수행할 수 있습니다.

OnLockingConfiguration은 EF가 앱 도메인에 대한 모든 EF 구성을 가져올 위치를 결정한 후 사용을 위해 잠기기 전에 호출됩니다. 앱 시작 시(EF 사용 전) 앱에 이 이벤트에 대한 이벤트 처리기를 등록해야 합니다. (이 처리기를 구성 파일에 등록하기 위한 지원 추가를 고려하고 있지만 아직 지원되지 않습니다.) 이벤트 처리기는 래핑해야 하는 모든 서비스에 대해 ReplaceService를 호출합니다.

예를 들어 IDbConnectionFactory 및 DbProviderService를 래핑하려면 다음과 같은 처리기를 등록해야 합니다.

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

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

해결된 서비스 및 이제 서비스를 해결하는 데 사용된 키와 함께 래핑되어야 하는 서비스가 처리기에 전달됩니다. 그런 다음 처리기는 이 서비스를 래핑하고 반환된 서비스를 래핑된 버전으로 바꿀 수 있습니다.

EF를 사용하여 DbProviderFactory 해결

DbProviderFactory는 위의 공급자 유형 개요 섹션에 설명된 대로 EF에 필요한 기본 공급자 유형 중 하나입니다. 이미 언급했듯이 이는 EF 형식이 아니며 등록은 일반적으로 EF 구성에 포함되지 않지만, 대신 machine.config 파일 및/또는 애플리케이션 구성 파일에서 일반적인 ADO.NET 공급자 등록입니다.

이 EF는 사용할 DbProviderFactory를 찾는 경우에도 여전히 정상적인 종속성 해결 메커니즘을 사용합니다. 기본 확인자는 구성 파일에서 일반 ADO.NET 등록을 사용하므로 일반적으로 투명합니다. 그러나 일반적인 종속성 해결 메커니즘이 사용되기 때문에 정상적인 ADO.NET 등록이 수행되지 않은 경우에도 IDbDependencyResolver를 사용하여 DbProviderFactory를 해결할 수 있습니다.

이러한 방식으로 DbProviderFactory를 확인하면 다음과 같은 몇 가지 의미를 확인할 수 있습니다.

코드 기반 구성을 사용하는 애플리케이션은 해당 DbConfiguration 클래스에 호출을 추가하여 적절한 DbProviderFactory를 등록할 수 있습니다. 이는 파일 기반 구성을 전혀 사용하지 않으려는(또는 사용할 수 없는) 애플리케이션에 특히 유용합니다.
위의 래핑 공급자 섹션에 설명된 대로 ReplaceService를 사용하여 서비스를 래핑하거나 바꿀 수 있습니다.
이론적으로 DbProviderServices 구현은 DbProviderFactory를 해결할 수 있습니다.

이러한 작업을 수행하는 방법에 대해 유의해야 할 중요한 점은 EF별 DbProviderFactory 조회에만 영향을 미친다는 것입니다. 다른 비EF 코드는 여전히 ADO.NET 공급자가 정상적인 방식으로 등록될 것으로 예상할 수 있으며 등록을 찾을 수 없는 경우 실패할 수 있습니다. 이러한 이유로 일반적으로 DbProviderFactory를 정상적인 ADO.NET 방식으로 등록하는 것이 좋습니다.

EF를 사용하여 DbProviderFactory를 해결하는 경우 IProviderInvariantName 및 IDbProviderFactoryResolver 서비스도 해결해야 합니다.

IProviderInvariantName은 지정된 유형의 DbProviderFactory에 대한 공급자 고정 이름을 확인하는 데 사용되는 서비스입니다. 이 서비스의 기본 구현에서는 ADO.NET 공급자 등록을 사용합니다. 즉, DbProviderFactory가 EF에서 해결되기 때문에 ADO.NET 공급자가 정상적인 방식으로 등록되지 않은 경우 이 서비스를 해결해야 합니다. DbConfiguration.SetProviderFactory 메서드를 사용할 때 이 서비스에 대한 확인자가 자동으로 추가됩니다.

위의 공급자 유형 개요 섹션에 설명된 대로 IDbProviderFactoryResolver는 지정된 DbConnection 개체에서 올바른 DbProviderFactory를 가져오는 데 사용됩니다. .NET 4에서 실행할 때 이 서비스의 기본 구현은 ADO.NET 공급자 등록을 사용합니다. 즉, DbProviderFactory가 EF에서 해결되기 때문에 ADO.NET 공급자가 정상적인 방식으로 등록되지 않은 경우 이 서비스를 해결해야 합니다.

다음을 통해 공유