7

Code First を使用したシード処理の例はたくさんありますが、EF Database First を使用する場合のデータベースのシード処理の慣用的な方法を理解しているかどうかはわかりません。

4

1 に答える 1

1

ベスト プラクティスは状況に大きく依存します。次に、DEV 環境と PROD 環境があります。DEV 中のモデル変更時に Drop and recreate を使用する場合の自動シードにより、テスト データが最も理にかなっています。この時が一番多かったです。

当然のことながら、手動でトリガーするテスト メソッドを使用できます。個人的には、自動的にトリガーされるシード メソッドというアイデアは、それほど刺激的ではなく、DB 構造が揮発性である場合の DEV プロトタイピングに適していると思います。移行を使用する場合、苦労して獲得したテスト データを保持する傾向があります。PROD での初期インストール時に Seeding を使用するものもあります。その他には、インストール/試運転プロセス中にトリガーされる特定のロード ルーチンがあります。代わりに、カスタム ロード ルーチンを使用するのが好きです。

編集:コードの最初のサンプル。DB First では、通常どおり Db に書き込むだけです。

// select the appropriate initializer for your situation eg
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, MyMigrationConfiguration>());
Context.Database.Initialize(true);  // yes now please
//...
 public class MyMigrationConfiguration<TContext> : DbMigrationsConfiguration<TContext> 
    where TContext  : DbContext{

    public  MyMigrationConfiguration() {
        AutomaticMigrationsEnabled = true;  //fyi  options
        AutomaticMigrationDataLossAllowed = true; //fyi options
   }
    public override void Seed(TContext context)
    {
        base.Seed(context);
// SEED AWAY..... you have the context
    }

}
于 2013-05-11T04:04:37.137 に答える