前回は、EF Core のクエリ実行と追跡を見ました。
今回は、EF Core のコマンドライン操作とマイグレーションを扱います。
モデルとデータベーススキーマを継続的に合わせるには、マイグレーションの理解が欠かせません。
ツールをインストールする
EF Core のコマンドライン操作には、dotnet ef を使います。
グローバルツールとしてインストールする例です。
dotnet tool install --global dotnet-ef
更新する場合です。
dotnet tool update --global dotnet-ef
確認します。
dotnet ef --version
プロジェクト側には、設計時に必要なパッケージも追加します。
dotnet add package Microsoft.EntityFrameworkCore.Design
SQL Server を使うなら、プロバイダーも必要です。
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
マイグレーションとは
マイグレーションは、モデル変更をデータベーススキーマ変更として記録する仕組みです。
たとえば、Car に Year プロパティを追加したとします。
public sealed class Car
{
public int Id { get; set; }
public string Make { get; set; } = "";
public string Color { get; set; } = "";
public string PetName { get; set; } = "";
public int Year { get; set; }
}
この変更をマイグレーションとして追加します。
dotnet ef migrations add AddCarYear
すると、変更内容を表す C# ファイルが生成されます。
概念的には、次のような処理が含まれます。
migrationBuilder.AddColumn<int>(
name: "Year",
table: "Inventory",
nullable: false,
defaultValue: 0);
マイグレーションは「モデルの変更履歴」です。
データベースへ反映する
追加したマイグレーションをデータベースへ適用します。
dotnet ef database update
これにより、モデル変更に対応する SQL が実行され、データベーススキーマが更新されます。
特定のマイグレーションまで戻すこともできます。
dotnet ef database update InitialCreate
開発環境では便利ですが、本番環境では SQL スクリプトを生成してレビュー・適用する運用もよくあります。
SQL スクリプトを生成する
マイグレーションから SQL スクリプトを生成できます。
dotnet ef migrations script
開始点と終了点を指定することもできます。
dotnet ef migrations script InitialCreate AddCarYear
本番反映では、生成された SQL を確認し、DBA や運用ルールに合わせて適用することがあります。
マイグレーション一覧を確認する
dotnet ef migrations list
適用済みかどうかを確認することで、開発環境や検証環境の状態を把握できます。
不要になった最後のマイグレーションを削除する場合です。
dotnet ef migrations remove
ただし、すでに共有環境や本番環境へ適用したマイグレーションを安易に削除するのは危険です。
チーム開発では、マイグレーション履歴も共有物として扱いましょう。
データベースを削除・更新する
開発環境では、データベースを削除して作り直したいことがあります。
dotnet ef database drop
その後、再作成します。
dotnet ef database update
これは学習環境やローカル開発環境では便利ですが、本番では基本的に使いません。
DbContext 情報を確認する
プロジェクトに複数の DbContext がある場合、一覧を確認できます。
dotnet ef dbcontext list
特定のコンテキストを指定してコマンドを実行する場合です。
dotnet ef migrations add InitialCreate --context AutoLotContext
情報を表示することもできます。
dotnet ef dbcontext info
複数のデータベースや境界づけられたコンテキストを持つアプリケーションでは、対象コンテキストを明示するのが安全です。
既存データベースからモデルを生成する
既存のデータベースから DbContext とエンティティを生成できます。
dotnet ef dbcontext scaffold \
"Server=localhost,1433;Database=AutoLot;User Id=sa;Password=YourStrong!Passw0rd;TrustServerCertificate=True;" \
Microsoft.EntityFrameworkCore.SqlServer \
--context AutoLotContext \
--output-dir Models
この方法は、すでに存在するデータベースを EF Core から扱いたい場合に便利です。
ただし、生成されたコードをそのままドメインモデルとして使うと、データベース都合がアプリケーション設計へ強く入り込むことがあります。
必要に応じて、データアクセス用モデルとドメインモデルを分ける設計も検討します。
設計時 DbContext ファクトリ
コマンド実行時に DbContext を作れない場合、設計時ファクトリを用意できます。
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Design;
public sealed class AutoLotContextFactory
: IDesignTimeDbContextFactory<AutoLotContext>
{
public AutoLotContext CreateDbContext(string[] args)
{
var options = new DbContextOptionsBuilder<AutoLotContext>()
.UseSqlServer(
"Server=localhost,1433;Database=AutoLot;User Id=sa;Password=YourStrong!Passw0rd;TrustServerCertificate=True;")
.Options;
return new AutoLotContext(options);
}
}
アプリ本体の起動設定に依存せず、dotnet ef がコンテキストを作成できるようになります。
マイグレーション運用の注意点
マイグレーションは便利ですが、運用には注意が必要です。
- 生成された差分をレビューする
- 本番データが消えないか確認する
- カラム名変更と削除の扱いに注意する
- チームでマイグレーションの競合を避ける
- 本番反映では SQL スクリプト化も検討する
- ロールバック方針を決めておく
特に、プロパティ名を変えただけでも、EF Core が「古い列を削除して新しい列を追加」と判断することがあります。
その場合、データが失われる可能性があります。
マイグレーションは自動生成されたから正しい、ではありません。
生成された内容を読む習慣が大切です。
まとめ
EF Core のコマンドライン操作を使うと、マイグレーション追加、データベース更新、スクリプト生成、既存データベースからのモデル生成ができます。
マイグレーションは、モデルとデータベースの差分を履歴として管理する強力な仕組みです。
ただし、本番データに影響する操作でもあるため、生成内容の確認と運用ルールが重要です。
ここまでで、EF Core の役割、基本部品、クエリ実行、追跡、マイグレーションの全体像を押さえました。
次に EF Core を深掘りするときは、関連データの読み込み、追加・更新・削除、グローバルフィルター、値変換、同時実行制御など、より実務的な機能へ進めます。