Entity Frameworkでの自動データベース移行

ソフトウェア開発のプロセスでは、すべての機能が最終的に定義されていない場合、データベース構造がしばしば変更されます。 また、ORMフレームワークを使用している場合、データモデルを変更した後にデータベースを変更すると不便になります(実際、モデルクラスとデータベース構造を変更するには二重の作業が必要です)。 簡単に言うと、パッケージマネージャーコンソールを使用してEF 4 Code Firstに移行する方法をここで説明しますが、開発者の参加なしで(より正確に、最小限の参加で)自動移行がどのように機能するかを説明します。





それがすべて始まった方法



タスクは、 AWPのような新しいプロジェクトを作成することでした。

協議した後、Entity Framework Code Firstを使用することにしました。 将来、 DBMSを変更することは可能です。このオプションでは、接続文字列を変更するだけで済みます(適切なADO.NETプロバイダーがある場合)。

DbContextから継承されたコンテキストクラスであるデータモデルを作成しました。



public class ProjectContext : DbContext { public ProjectContext() { } public ProjectContext(string connString) : base(connString) { } public DbSet<Address> Addresses { get; set; } ... }
      
      





初期化子を追加しました:



 public class ProjectInitializer : DropCreateDatabaseIfModelChanges<ProjectContext> { protected override void Seed(ProjectContext context) { ... } }
      
      





(Global.asaxの場合)イニシャライザーを記述します。



 Database.SetInitializer(new ProjectInitializer());
      
      





それを作成するための基盤を持っていない人はすべて素晴らしいようですが、顧客と詳細を明確にした後、さらにエンティティを追加する必要がありました。 また、複数の開発者が開発しているため、データベースの大規模な再作成が行われ、そこにあるデータはすでに現実のものでした。



移行



それで移行に来ました。 お勧めのとおり、この記事ではパッケージマネージャーコンソールでコマンドを実行しました。



 PM> Add-Migration 1
      
      





Migrationsフォルダーがプロジェクトに表示され、2つのファイルが作成されました:Configuration.cs、<date_time> _1.cs。 最初の名前は、その名前が示すとおり、移行構成です。2番目には、バージョンの更新/ロールバックに必要なデータベースの変更が含まれています。 次に、NuGetのコンソールで実行します。



 PM> Update-Database
      
      





すべてが素晴らしかったです。誰かのモデルがデータベースと一致しなかった場合、彼はコンソールで移行を行い、移行とともにファイルを削除しました。 顧客のサーバーにプロジェクトを配置する時が来るまで。 NuGetは存在せず、インストールする機会もありませんでした(そして、サーバーを使用しない場合、原則としてホスティングプロバイダーにはそのような機会があります)。



自動移行



科学的な突く方法を使用して、 IntelliSenseで武装した自動移行を行う方法を理解しようとすると、経験的方法は、イニシャライザが継承されるクラスを変更する必要があることを発見しました。



 //public class ProjectInitializer : DropCreateDatabaseIfModelChanges<ProjectContext> public class ProjectInitializer : MigrateDatabaseToLatestVersion<ProjectContext, Configuration> { ... }
      
      





起動してこの例外を受け取りました:







うん! 例外メッセージで提案されていることを行います。つまり:



 public sealed class Configuration : DbMigrationsConfiguration<ProjectContext> { public Configuration() { AutomaticMigrationsEnabled = true; } protected override void Seed(ProjectContext context) { } }
      
      





開始すると、移行が自動的に行われることがわかります。

開発者の参加なしに移行が行われるようになりましたが、たとえば、モデルプロパティの名前を変更してプロジェクトを開始した場合、次の例外が発生するなど、まだ参加が必要であると述べました。







事実、Entity Frameworkの観点からは、プロパティの名前を変更すると、新しい名前で削除および追加されるため、データが失われる可能性があります。 このような場合(およびそれらはほとんどありません)、Add-Migrationコマンドを使用して手動で移行を作成し、手動でDropColumnおよびCreateColumnをRenameColumn(または状況に応じて何か他のもの)に調整する必要があります。



おわりに



以上で、この記事が役立つことを願っています。 また、この問題に関する元のソースからの情報がほとんどないことを願っています。これは一種のベータ版であり、Entity Framework 5.0のリリースでは、試行錯誤によって正しいユースケースを検索する必要がないためです。



All Articles