1

最初のソリューションでは、web.config で System.Data.Entity.Infrastructure.LocalDbConnectionFactory を defaultConnectionFactory タイプとして設定していました。

<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
  <parameters>
    <parameter value="v11.0" />
  </parameters>

開発にはローカルの SQL Server を使用し、実際の展開には SQL Azure を使用しているため、実際にそのようにする必要があるかどうかはわかりません。EF Code First を使用し、PK_dbo.Customers や FK_dbo.Customers_dbo.Employers_EmployerID などの名前のキーを使用してテーブルを作成し、IX_EmployerID などの各外部キーに対してインデックスを作成します。

SQL Azure での一時的な障害に対する再試行ロジックを組み込みたいため、Robert Moore によって作成された ReliableDbProvider のこの投稿のアイデアに基づいて、カスタム接続ファクトリに切り替えました。正常に動作しているように見えますが、キーの名前が異なり (PK__Customer__A4AE64B8BB3388DF、Customer_Employer)、インデックスが生成されないようです。

工場が世代に影響を与えるとは思っていませんでした。それがどのように貢献するか考えていますか?

いくつかのコードを反映した後、それは DropCreateDatabaseIfModelChanges イニシャライザー内で使用される DbMigrationsConfiguration クラスが機能する方法に関係しているように思われるので、何らかの方法でオーバーライドできるかどうかを確認する必要があります。

public DbMigrationsConfiguration()
{
this.SetSqlGenerator("System.Data.SqlClient", new SqlServerMigrationSqlGenerator());
this.SetSqlGenerator("System.Data.SqlServerCe.4.0", new SqlCeMigrationSqlGenerator());
this.CodeGenerator = new CSharpMigrationCodeGenerator();
}

まだまだアイデア募集中!

4

1 に答える 1