「Entity Framework 6（EF6）」と「Entity Framework Core（EFCore）」のマイグレーション方法

こんにちは！
今日は 「Entity Framework 6（EF6）」と「Entity Framework Core（EFCore）」のマイグレーション方法 をがっつり深掘りしたいと思います。

「EF のマイグレーションって名前は聞くけど、実際どう動くの？」
「EFCore のほうが良いって言うけど、結局どうして？」

こんなモヤモヤを抱えたままコードを書いているあなたの背中を、そっと押す記事にできたら嬉しいです。

1. そもそも“マイグレーション”ってなに？

マイグレーション（Migration）は、「アプリのモデル → DB スキーマ」 を自動で同期させる仕組みです。
たとえばクラスに IsDeleted プロパティを追加したら、自動で DB のテーブルにも IsDeleted 列を増やしてくれるイメージですね。

  • 好きな料理をレシピ通りに作る ⇒ モデルをクラス通りに DB に反映
  • レシピを変えたら作り方も変わる ⇒ モデルを変えたら DB も更新

こう言うとシンプルですが、手動で ALTER TABLE を書くよりはるかに安全で楽チンです。

2. EF6 のマイグレーション方法

2-1. 前準備：有効化は一度きり

Visual Studio の Package Manager Console（以下 PMC）で――

Enable-Migrations

初回だけ走らせると、Migrations フォルダーと Configuration.cs が生成されます。
いわば「ここからマイグレーションやるよ！」という宣言ですね。

2-2. 差分をコードにする：Add-Migration

Add-Migration InitialCreate

クラスと DB の差分が C# コードで生成されます。Git でレビューできるので、「どんな SQL が走るか見える化」 できるのが安心ポイントです。

2-3. DB を更新：Update-Database

Update-Database

生成された差分を SQL に展開して DB を更新します。
ロールバックしたいときは -TargetMigration オプションも覚えておくと便利です。

2-4. 接続文字列の“name=”落とし穴

EF6 では DbContext のコンストラクターに base("name=MyConnection") と書く必要があります。

public MyDbContext() : base("name=MyConnection") { }

name= を忘れると “接続文字列が見つからない” と怒られてハマるので要注意です。地味だけど痛い罠…。

3. EFCore のマイグレーション方法

「CLI？ PMC？ どっちを使うの？」
→ 基本は .NET CLI（dotnet ef）で統一 しておくとクロスプラットフォームでも安心です。

3-1. ツールをインストール

dotnet tool install --global dotnet-ef

グローバル インストールなので、どのプロジェクトでも dotnet ef が使えます。

3-2. 差分を作成：migrations add

dotnet ef migrations add InitialCreate

Migrations フォルダーができ、差分クラスが追加されます。VSCode でも Rider でも同じコマンドで OK なのが嬉しいですね。

3-3. DB を更新：database update

dotnet ef database update

マンドはたったこれだけ。--connection オプションで一時的に別環境に当てることもできます。

3-4. よく使う便利コマンド

目的コマンド
既存マイグレーション一覧dotnet ef migrations list
直前の差分を取り消すdotnet ef migrations remove
SQL のみ生成して確認dotnet ef migrations script

SQL を眺めてレビュー → OK なら database update、という流れが鉄板です。

3-5. 接続文字列は DI で注入

services.AddDbContext<MyDbContext>(options =>
    options.UseSqlServer(Configuration.GetConnectionString("MyConnection")));

EFCore ではコンテキストを DI（依存性注入） で組み立てるのが定番です。
base("name=...") の呪文から卒業できるのは地味に快感ですよ。

4. 「新規プロジェクトでは、EFCore を選ぶと幸せになる」４つの理由

  1. マルチプラットフォーム
    Windows 以外にも Linux・macOS・Docker コンテナ上でも動きます。CI/CD も楽々。
  2. パフォーマンスの改善
    追跡クエリの最適化やバッチ更新など、EF6 時代の“もっさり”をかなり解消。
  3. アップデートが活発
    .NET 8 世代では年２回の大きなアップデートがほぼ確実。Bulk Insert や JSON 列 へのマッピングなど今風の機能が次々に入ってきます。
  4. 設計が柔軟
    IDesignTimeDbContextFactory で複数 DB に対応したり、UseCosmos で NoSQL にもつないだり。「RDB だけ」の枠を超えた設計 ができます。

5. とはいえ「EF6 のまま」が正解になるケースもある

  • 既に稼働中で大規模
    マイグレーションが何百本もあるプロダクトを丸ごと EFCore に変えるのは、テストと検証コストが尋常じゃありません。
  • 第三者パッケージ依存
    古いレポート系ライブラリなど、EF6 にしかフックしていない場合は移行コストが跳ね上がります。

要するに 「新規開発 → EFCore」「保守だけなら EF6 のまま」 が無難な落としどころです。

6. よくある “あるある” Q&A

Q. “dotnet ef が見つかりません”
A. グローバルツールを入れ忘れているか、PATH が通っていない可能性大です。dotnet tool list -g で確認してみてください。

Q. “モデルを削除したのに列が残る”
A. 差分が正しく生成されていないか、Update-Database を忘れているかのどちらかです。dotnet ef migrations remove → 再度 add してみると解決することが多いです。

Q. “テスト用 DB だけスキーマを分けたい”
A. EFCore なら --connection オプションで一時的に別接続文字列を指定できます。CI で使うと便利ですよ。

7. まとめ － マイグレーションは“基本のキ”

比較項目EF6EFCore
マイグレーション実行Add-Migration → Update-Database（PMC）dotnet ef migrations add → database update
OS 対応Windows メインクロスプラットフォーム
アップデート状況ほぼ保守のみ継続的な新機能追加
パフォーマンスやや重い高速化済み
推奨シナリオレガシー保守新規開発

というわけで――

  • 新しく作るなら EFCore 一択
  • 既存の巨大プロジェクトは EF6 継続でも OK

この大原則さえ押さえておけば、大きく道を踏み外すことは少ないはずです。

8. さいごに

マイグレーションは、「自動で DB をいい感じに保ってくれる家政婦さん」 のような存在です。
とはいえ、魔法ではなくあくまでツール。使い方を誤ればテーブル構造を壊すこともあります。

とはいえ（２回目）――怖がり過ぎて手動 SQL に戻ると、二度と帰れない沼 が待っています。
まずはローカルで dotnet ef migrations add TryItOut を打ってみてください。

「あ、こんなに簡単に列が増えた！」

その驚きが、次の一歩の原動力になるはずです。
というわけで 今日は EF のマイグレーション事情をお届けしました。

少しでも “触ってみようかな” と思ってもらえたら嬉しいです。
ではでは、良き Entity Framework ライフを！

タグ

関連投稿