構成ファイルの設定
Entity Framework では、構成ファイルからさまざまな設定を指定できます。 一般に、EF は "Convention over Configuration (構成より規約)" の原則に従います。この記事で取り上げるすべての設定には既定の動作があるので、既定の動作で要件が満たせないときにだけ設定を変更すればよく、それ以外で気を配る必要はありません。
同じことをコードで行う
これらの設定はいずれもコードを使用して適用することもできます。 EF6 以降ではコードベースの構成が導入され、コードから構成を適用する主要な手段となっています。 EF6 未満でもコードから構成を適用することはできますが、さまざまな領域を構成するために、各種の API を使用する必要があります。 デプロイ中に構成ファイルを使えば、コードを更新しなくても、これらの設定を簡単に変更できます。
Entity Framework の構成セクション
EF4.1 以降では、構成ファイルの appSettings セクションを使用して、コンテキストのデータベース初期化子を設定できるようになりました。 EF 4.3 では、新しい設定を処理するカスタム entityFramework セクションが導入されました。 引き続き以前の形式を使用して設定されたデータベース初期化子も Entity Framework によって認識されますが、できる限り、新しい形式に移行することをお勧めします。
entityFramework セクションは、EntityFramework NuGet パッケージをインストールしたときに、プロジェクトの構成ファイルに自動的に追加されています。
<?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>
接続文字列
このページでは、構成ファイル内の接続文字列を含め、使用するデータベースを Entity Framework がどのように特定するかについて詳しく説明します。
接続文字列は標準の connectionStrings 要素に格納されるので、entityFramework セクションは必要ありません。
Code First ベースのモデルでは、通常の ADO.NET 接続文字列が使用されます。 次に例を示します。
<connectionStrings>
<add name="BlogContext"
providerName="System.Data.SqlClient"
connectionString="Server=.\SQLEXPRESS;Database=Blogging;Integrated Security=True;"/>
</connectionStrings>
EF Designer ベースのモデルでは、特殊な EF 接続文字列が使用されます。 次に例を示します。
<connectionStrings>
<add name="BlogContext"
connectionString=
"metadata=
res://*/BloggingModel.csdl|
res://*/BloggingModel.ssdl|
res://*/BloggingModel.msl;
provider=System.Data.SqlClient;
provider connection string=
"data source=(localdb)\mssqllocaldb;
initial catalog=Blogging;
integrated security=True;
multipleactiveresultsets=True;""
providerName="System.Data.EntityClient" />
</connectionStrings>
コードベースの構成タイプ (EF6 以降)
EF6 以降では、アプリケーションのコードベースの構成に EF で使用される DbConfiguration を自分で指定できます。 DbConfiguration は EF によって自動的に検出されるため、ほとんどの場合、この設定を自分で指定する必要はありません。 構成ファイルに自分で DbConfiguration を指定すべきケースについて詳しくは、「コードベースの構成」の「DbConfiguration を移動する」セクションを参照してください。
DbConfiguration 型を設定するには、codeConfigurationType 要素にアセンブリの修飾型名を指定します。
Note
アセンブリの修飾名は、<名前空間の修飾名> + <コンマ> + <型が存在するアセンブリ> という形式になります。 必要に応じてアセンブリのバージョン、カルチャ、公開キー トークンを指定することもできます。
<entityFramework codeConfigurationType="MyNamespace.MyConfiguration, MyAssembly">
</entityFramework>
EF のデータベース プロバイダー (EF6 以降)
EF6 未満では、データベース プロバイダーの中の Entity Framework 固有の要素を、コア ADO.NET プロバイダーの構成要素として追加する必要がありました。 EF6 以降では、EF 固有の要素が個別に管理、登録されます。
通常、プロバイダーを自分で登録する必要はありません。 これは通常、インストール時にプロバイダーによって行われます。
プロバイダーは、entityFramework セクションの子セクション providers に provider 要素を追加することで登録されます。 プロバイダー エントリには次の 2 つの必須属性があります。
- invariantName は、この EF プロバイダーのターゲットとなるコア ADO.NET プロバイダーを識別します。
- type は、EF プロバイダーの実装のアセンブリ修飾型名です。
Note
アセンブリの修飾名は、<名前空間の修飾名> + <コンマ> + <型が存在するアセンブリ> という形式になります。 必要に応じてアセンブリのバージョン、カルチャ、公開キー トークンを指定することもできます。
以下に示したのは、Entity Framework をインストールするときに既定の SQL Server プロバイダーを登録する目的で作成されたエントリの例です。
<providers>
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
</providers>
インターセプター (EF6.1 以降)
EF6.1 以降では、構成ファイルでインターセプターを登録できます。 インターセプターを使用すると、データベース クエリの実行や接続のオープンなど、EF が特定の操作を実行する際に追加のロジックを実行できます。
インターセプターは、entityFramework セクションの子セクション interceptors に interceptor 要素を追加することで登録されます。 たとえば次の構成では、すべてのデータベース操作をコンソールにログする組み込みの DatabaseLogger インターセプターを登録しています。
<interceptors>
<interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework"/>
</interceptors>
データベース操作をファイルにログする (EF6.1 以降)
問題をデバッグしやすいよう、既存のアプリケーションにログ機能を追加したい場合には、構成ファイルを用いたインターセプターの登録は特に効果的です。 DatabaseLogger では、ファイル名をコンストラクター パラメーターとして指定することによって、ファイルへのログ記録がサポートされます。
<interceptors>
<interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
<parameters>
<parameter value="C:\Temp\LogOutput.txt"/>
</parameters>
</interceptor>
</interceptors>
既定では、アプリが起動するたびにログ ファイルが新しいファイルで上書きされます。 既存のログ ファイルに追加する場合は、次のようにします。
<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>
DatabaseLogger とインターセプターの登録について詳しくは、再コンパイルせずにログを有効にする方法 (EF 6.1) のブログ記事を参照してください。
Code First の既定の接続ファクトリ
構成セクションでは、コンテキストに用いるデータベースを検索する際に Code First に使用させる既定の接続ファクトリを指定できます。 既定の接続ファクトリが使用されるのは、コンテキストの構成ファイルに接続文字列が追加されていないときだけです。
EF NuGet パッケージをインストールした場合、SQL Express と LocalDB のどちらがインストールされているかに応じて、SQL Express または LocalDB を指す既定の接続ファクトリが登録されています。
接続ファクトリを設定するには、defaultConnectionFactory 要素にアセンブリの修飾型名を指定します。
Note
アセンブリの修飾名は、<名前空間の修飾名> + <コンマ> + <型が存在するアセンブリ> という形式になります。 必要に応じてアセンブリのバージョン、カルチャ、公開キー トークンを指定することもできます。
既定の接続ファクトリを独自に設定する例を次に示します。
<entityFramework>
<defaultConnectionFactory type="MyNamespace.MyCustomFactory, MyAssembly"/>
</entityFramework>
上の例は、このカスタム ファクトリのコンストラクターにはパラメーターがないという指定になっています。 必要であれば、parameters 要素を使用してコンストラクターのパラメーターを指定できます。
たとえば、Entity Framework に含まれている SqlCeConnectionFactory では、プロバイダーのインバリアント名をコンストラクターに渡す必要があります。 プロバイダーのインバリアント名によって、使用したい SQL Compact のバージョンが識別されます。 次のように構成した場合、コンテキストでは、SQL Compact バージョン 4.0 が既定で使用されます。
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlCeConnectionFactory, EntityFramework">
<parameters>
<parameter value="System.Data.SqlServerCe.4.0" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
既定の接続ファクトリを設定しなかった場合は、.\SQLEXPRESS を指す SqlConnectionFactory が Code First によって使用されます。 SqlConnectionFactory にも、接続文字列の一部をオーバーライドできるコンストラクターがあります。 .\SQLEXPRESS 以外の SQL Server インスタンスを使用する場合は、そのコンストラクターを使用してサーバーを設定できます。
次のように構成した場合、明示的な接続文字列が設定されていないコンテキストには、Code First によって MyDatabaseServer が使用されます。
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
<parameters>
<parameter value="Data Source=MyDatabaseServer; Integrated Security=True; MultipleActiveResultSets=True" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
既定では、コンストラクターの引数は文字列型と見なされます。 これは type 属性を使用して変更できます。
<parameter value="2" type="System.Int32" />
データベース初期化子
データベース初期化子は、コンテキスト単位で構成されます。 これらは、構成ファイルで context 要素を使用して設定できます。 この要素では、アセンブリの修飾名を使用して、構成対象のコンテキストが特定されます。
既定では、CreateDatabaseIfNotExists 初期化子を使用するよう、Code First コンテキストが構成されます。 context 要素には disableDatabaseInitialization 属性があり、この属性を使用してデータベースの初期化を無効にすることができます。
たとえば次の構成では、MyAssembly.dll に定義されている Blogging.BlogContext コンテキストを対象に、データベースの初期化を無効にしています。
<contexts>
<context type=" Blogging.BlogContext, MyAssembly" disableDatabaseInitialization="true" />
</contexts>
databaseInitializer 要素を使用すると、カスタム初期化子を設定できます。
<contexts>
<context type=" Blogging.BlogContext, MyAssembly">
<databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly" />
</context>
</contexts>
コンストラクターのパラメーターには、既定の接続ファクトリと同じ構文が使用されます。
<contexts>
<context type=" Blogging.BlogContext, MyAssembly">
<databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly">
<parameters>
<parameter value="MyConstructorParameter" />
</parameters>
</databaseInitializer>
</context>
</contexts>
Entity Framework に含まれている、いずれかのジェネリックなデータベース初期化子を構成できます。 type 属性では、ジェネリック型に .NET Framework の形式が使用されます。
たとえば、Code First Migrations を使用している場合、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>
.NET
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示