こんばんは。この記事はASP.NETアドベントカレンダー2014の16日目となる記事です。

昨晩は、@masaru_b_clさんの、OWINについて #niigatapm #nds39 で発表してきました #aspnetjpでした。

今日は、Azure関連で考えてましたが、Code First Migrationsの方を書きたくなったので、マイグレーションで書きます!

ソリューション構成

ASP.NETでEntityFrameworkを利用するさいは、コードファーストマイグレーションを使用するのがナウい方法だと思っています。

ASP.NETをテンプレートで作成すると、ASP.NETのプロジェクトが1つ作られます。しかし、エンティティやデータアクセス層をASP.NETのから分離したい場合もあるかと思います。私は見通しがいいので分けているだけですが、たとえば、バッチなどを書く際に、データアクセス層がASP.NETプロジェクトから分離されていると便利かなと思います。

今回は次の図のように、ASP.NETプロジェクトからDBコンテキストを分離しつつ、ASP.NETプロジェクトのConnectionStringを用いて、複数のコンテキストをマイグレーションします。

image

マイグレーションの有効化

パッケージマネージャコンソールを開き、既定のプロジェクトをASP.NETプロジェクト、つまり、ここでは、SeparatedDbContextApplication.Webにします。

まずは、認証用のコンテキスト、IdentityContextのマイグレーションを有効化します。

Enable-Migrations -EnableAutomaticMigrations -ProjectName SepatedDbContextApplication.DataAccess -ContextTypeName IdentityContext -MigrationsDirectory IdentityContextMigrations

次に、データ用のコンテキスト、DataContextのマイグレーションを同様に有効化します。

Enable-Migrations -EnableAutomaticMigrations -ProjectName SepatedDbContextApplication.DataAccess -ContextTypeName DataContext -MigrationsDirectory DataContext Migrations 

すると、下図のようにDataAccessプロジェクトにマイグレーション用のコンフィグレーションがコンテキスト別に作成されます。

image

データベースの更新

Update-Databaseでマイグレーションを実行し、データベースを更新します。

Update-Database -ProjectName SepatedDbContextApplication.DataAccess -Configuration SepatedDbContextApplication.DataAccess.IdentityContextMigrations.Configuration
Update-Database -ProjectName SepatedDbContextApplication.DataAccess -Configuration SepatedDbContextApplication.DataAccess.DataContextMigrations.Configuration

マイグレーション完了後、サーバエクスプローラで確認するとテーブルが作成されています。

image

一応、__MigrationHistoryも確認してみます。

image

小さくてわかりにくいかもしれませんが、2つマイグレーションが実行されたことが記録されており、2つはContextKeyが異なります。よって、それぞれ別のコンフィグレーションを参照していることが確認できます。

まとめ

認証用のDBコンテキストとデータ用のDBコンテキストは分けた方が良いとか、層ごとにプロジェクト分けるとテストしやすかったり、ドメインがはっきりして、スパゲッティにならなくて良いとか聞いて、1ケ月くらい前に調べました。今は、こんなソリューション構成で作ってます。何か危険なとこがあれば突っ込んでいただけると嬉しいです。

今回使ったサンプルソリューションは、参考にはならないかもしれませんが、Githubにあげておきました。

明日は、味噌先生の記事です。非常に楽しみです!

CATEGORIES