Code First を使用したシード処理の例はたくさんありますが、EF Database First を使用する場合のデータベースのシード処理の慣用的な方法を理解しているかどうかはわかりません。
2877 次
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 に答える