EF Core 11 チートシート

EF Core は追跡中のエンティティのキー値を更新しません。DTO からのキーのコピーをやめ、代替キーの代わりに一意インデックスを使い、本当にキーを変える場合は新しい行を挿入して古い行を削除します。EF Core 10.0.14 で検証しています。

DbContext ごとに --output-dir を一度だけ指定すれば、以降のマイグレーションは同じフォルダーと名前空間に作成されます。既定のレイアウトが偏る理由、共有フォルダーで発生する CS0111 の衝突、既存マイグレーションの移動方法、履歴テーブルを分けるべきタイミングを解説します。

EF Core 11 で単一の User エンティティにフォロワーとフォロー中をモデル化します。規約が何を生成するか、SQL Server が結合テーブルの外部キーの片方を黙って ClientCascade に変える理由、タイムスタンプ付きの明示的な Follow 結合エンティティのマッピング方法、そしてエラー 547 や 1785 を出さずにユーザーを削除する方法を解説します。

決め手はスタートアッププロジェクトにある SQL Server プロバイダーの EF Core バージョンです。EF Core 7 以前は date を DateTime に、EF Core 8 から 11 までは DateOnly にスキャフォールドします。この判断を行う型マッピング、EF Core 7、8、10、11 RC 2 での実測出力、そして列を黙って datetime2 に再マッピングすることなく DateTime に戻す 2 つの方法を紹介します。

Pomelo 9.0.0 は EF Core Relational 9.0.x しか許可しておらず、EF Core 10 向けのビルドもありません。EF Core のパッケージをすべて 9.0.x にそろえるか、Microting.EntityFrameworkCore.MySql 10.0.x に切り替えてください。警告を抑制すると起動時にクラッシュします。

ツールパッケージがインストールを実行している SDK よりも新しい .NET を対象としているか、そもそも .NET ツールではありません。新しい SDK を使うか、互換性のある tools フォルダーを持つツールのバージョンを固定するか、--framework を強制してください。

DbSet.Local.FindEntry(key) を使えば、データベースへの往復やスキャンなしで、指定したキーのエンティティが追跡されているかを変更トラッカーに問い合わせられます。この確認で Entry(entity).State が当てにならない理由、Find がクエリを発行する理由、EF Core 10 で検証済みの AttachOrMerge ヘルパーを紹介します。

コンパイル済みモデルとは、OnModelCreating を実行せずに EF Core のモデルを再構築する生成済み C# コードです。EF Core 11 RC1 での実測では、500 エンティティでモデルの読み込みが 714 ms から 215 ms に短縮されます。ただし EFOptimizeContext の後継である MSBuild 経由の方法は遅く、古くなったモデルはエラーなしで使われ続け、クエリフィルターがあると生成そのものができません。

shadow プロパティは、対応する CLR プロパティがないまま EF Core が追跡する列です。EF Core 11 がそれを作る理由 (FK プロパティの欠落、FK の命名ミス、型の不一致、リレーションシップの二重構成)、マイグレーションで BlogId1 のような列を見つける方法、原因ごとの修正方法、そして意図的に shadow プロパティを使う方法を解説します。

AddDbContextPool は DI スコープごとに 1 つのスコープ付き DbContext を渡すため、2 つのクエリを同時に実行できません。AddDbContextFactory と AddPooledDbContextFactory は呼び出しごとにコンテキストを返すので、並列クエリに向いています。EF Core 11 RC 1 での計測では、プール付きファクトリはコンテキストを 342 ns、40 B で作成しますが、プールなしでは 17 us、44 KB かかります。

EF Core は、First、Where、Max、Single を追加した時点で、スカラーの SqlQuery<T> をサブクエリでラップし、Value という名前の列を選択します。SQL の列に AS Value のエイリアスを付けるか、先にマテリアライズしてください。

Migrations フォルダーを削除して新しい InitialCreate を生成すると、EF Core はテーブルが既に存在することを知りません。開発用データベースを削除するか、新しいマイグレーションを実行せずに __EFMigrationsHistory に記録します。

一度だけ実行した SET は、Npgsql が接続をプールに戻した瞬間に DISCARD ALL で消去されます。Search Path と Options の接続文字列キーワードで search_path と statement_timeout をスタートアップパケットに含め、うまくいかない場合は ALTER ROLE か ConnectionOpened インターセプターにフォールバックします。また、UsePhysicalConnectionInitializer の SET が黙って失われる理由も解説します。

EF.Constant はキャプチャした値を SQL リテラルとして埋め込み、EF.Parameter はリテラルを SQL パラメーターに変換します。基本は EF Core の既定のままにし、動的に組み立てた式ツリーが呼び出しのたびに再コンパイルされるのを防ぐには EF.Parameter を使います。EF.Constant は、値の種類が少なく、データの偏りが大きくて値ごとに別のプランが必要な場合だけに使います。

EF Core 8、9、10 では、リストが IList、ICollection、ISet、IReadOnlySet 型の static readonly フィールドの場合、Contains を変換できません。Enumerable.Contains を明示的に呼び出すか、EF Core 11 にアップグレードしてください。

EF Core 11 RC 1 では、ToJson() メンバーに対する HasIndex(...).IsUnique() は一意性を強制しません。SQL Server は IsUnique を無視し、SQLite はドキュメント全体にインデックスを張ります。JSON の値を計算列として公開し、その列に一意インデックスを設定してください。

エンティティを読み込み、List.Add を呼んで保存すると、jsonb ドキュメント全体が書き換えられ、同時に行われた追加は黙って失われます。追加処理は jsonb の || 演算子を使った 1 つの UPDATE にまとめます。ExecuteSqlAsync を使うか、ExecuteUpdateAsync の中でマップした関数を使い、さらに @> によるガードで冪等にします。

Oracle.EntityFrameworkCore 10 の UseSequence で EF Core のキーを Oracle のシーケンスにマッピングします。プロバイダーが実際に出力する DDL と INSERT の SQL、既存のシーケンスやレガシーなトリガーを使う方法、引用符と HiLo でつまずきやすい理由、そして ORA-00001 を起こさずに ID 列をシーケンスへ移行する方法を解説します。

Gas という名前のテーブルは Ga というエンティティにスキャフォールドされます。組み込みの Humanizer 複数形化サービスを独自の IPluralizer に置き換え、スタートアッププロジェクトの IDesignTimeServices から登録する方法と、そこで TryAddSingleton が黙って何もしない理由を解説します。

ハンドラーの存在チェックは、あなたが思っているようなガードではありません。inbox テーブルに一意インデックスを張り、業務上の変更と同じ SaveChanges でマーカーを書き込み、勝者はデータベースに決めさせます。さらに、それを静かに台無しにする ExecuteUpdate の罠も扱います。

EF Core 11 が生成する PK_、FK_、AK_、IX_ の名前を 1 つの IModelFinalizingConvention ですべて付け替え、明示的に指定した名前を優先させ、識別子の長さ制限に収め、既存データベースで次のマイグレーションが生成するクラスター化インデックスの再構築を回避します。

EF Core 11 は Cosmos DB の生成 id 値に含まれる '/', '\', '?', '#' をエスケープしなくなったため、EF Core 8-10 で書き込んだドキュメントがキーで解決できなくなります。影響を受けるかどうかの確認方法、EscapeIllegalCosmosIdCharacters スイッチを設定すべき場面、そしてトランザクションバッチで id を安全に書き換える方法を解説します。

EF Core 11 では UseSqlServer の既定の互換性レベルが 160 になり、LEAST、GREATEST、2 引数の LTRIM/RTRIM が SQL に入るようになりました。すべての Take(n).FirstOrDefault() も対象です。SQL Server 2022 以降なら 160 のままにし、SQL Server 2019 がまだ動いている環境が一つでもあれば UseCompatibilityLevel(150) で固定してください。

EF Core の SQL Server 存在チェックは、EnableRetryOnFailure の有無にかかわらずエラー 18456 を丸 1 分間リトライします。即座に失敗させるか、RetryTimeout を短くするか、EF Core 12 を待ってください。

EF Core 11 は Microsoft.Data.SqlClient 7.0.0.0 に対してコンパイルされていますが、リストアまたはデプロイで 6.x のコピーが採用されてしまっています。古い SqlClient の固定指定を削除し、出力全体を再デプロイしてください。

Select が SQL の NULL を null 非許容の int、decimal、DateTime に読み込もうとすると、EF Core はこの例外をスローします。メンバーを null 許容型にキャストして ?? default を付けるか、ナビゲーションを null チェックで保護してください。

EF Core 11 では StartsWith、EndsWith、Contains が % と _ を自動でエスケープしますが、EF.Functions.Like はエスケープしません。EF が生成する SQL、再利用できるエスケープヘルパー、そして SQL Server、SQLite、PostgreSQL で正しく動作させるための escapeCharacter オーバーロードを解説します。

SQL Server 2025 と Azure SQL ではネイティブの json 型を使いましょう。EF Core 11 はそこから JSON_CONTAINS、型付きの JSON_VALUE、インプレースの modify()、JSON インデックスを引き出せます。SQL Server 2019/2022、レガシーなツール、あるいはロールバックできる必要があるスキーマの場合は nvarchar(max) のままにしてください。

EF Core のビルド時モデル生成が MSBuild を再帰的に呼び出し、RAM を使い切っていました。Tasks と Design を 10.0.10 以降に更新し、EF Core 11 では EFOptimizeContext を削除します。

EF Core が OPENJSON WITH の内部に [col] json '$.path' AS JSON を出力し、Azure SQL が Msg 13618 で拒否します。EF Core 10.0.11 以降へ更新するか、プロバイダーの互換性レベルを 160 に下げてください。

Microsoft.EntityFrameworkCore を 10.0.10 以降へ更新してください。それ以前は、2 つ目の ToJson 複合プロパティ配下でネストしたコレクションが増えると SaveChanges が失敗しました。

EF Core 10.0.x では、ToJson の複合コレクション内で 2 要素のコレクションを持つ複合プロパティに null を代入すると DetectChanges が壊れます。11.0.0-rc.1 で修正されました。

Tools 10.0.6 が一致するバージョンの Microsoft.EntityFrameworkCore.Design を取得しなくなったため、dotnet ef が ArgumentIsEmpty で MissingMethodException を投げます。Design を EF Core のバージョンに固定してください。

EF Core 11 にはいまだにロック用の API がありません。FromSql で実際の行ロックを取る方法を解説します。SQL Server では WITH (UPDLOCK, ROWLOCK)、PostgreSQL では FOR UPDATE、ロック範囲を静かに広げてしまうサブクエリの罠、NOWAIT と SKIP LOCKED、デッドロックのリトライ、そして行がまだ存在しない場合の対処法まで。

EF Core はデフォルトでは value converter に null を渡しません。それを変える内部 API の convertsNulls コンストラクター、依存する IsRequired(false) の呼び出し、enum などの値型でどうしても機能しない理由、生まれてしまう WHERE col = NULL の罠、そして内部 API を使わずに目的を果たす 2 つのパターンを解説します。

EF Core のインターセプターは、コマンドの実行や SaveChanges といった操作の前後で EF が呼び出すクラスで、観察するだけでなく操作を変更したり抑制したりできます。EF Core 11 の 7 つのインターセプトポイント、登録とライフタイムの規則、そしてクエリフィルターやログ出力のほうが適している場面をまとめます。

ハンドラーの「確認してから挿入」はアトミックではありません。SqlState 23505 の PostgresException を捕捉するか、全体を 1 つの INSERT ... ON CONFLICT 文にまとめてください。EnableRetryOnFailure は役に立ちません。

EF Core の Migrate() は常にデータベースの存在を確認し、なければハードコードされた master 接続で作成します。CREATE ANY DATABASE を付与するか、既存データベースへのログインのアクセスを直すか、冪等な SQL スクリプトを配布してください。

iOS ビルドは DynamicCodeSupport=false を設定するため、NativeAOT を有効にしていなくても EF Core はモデルの構築を拒否します。コンパイル済みモデルと事前コンパイル済みクエリを出荷するか、インタープリターを再び有効にしてください。

bool を返すヘルパーメソッドは "could not be translated" を投げますが、Expression<Func<T, bool>> は投げません。LINQKit なしで EF Core 11 の式ツリーを合成、入れ子、再利用する方法を、各ケースの実際の SQL 付きで解説します。

EF Core は、クライアント評価されるクエリの一部が評価中に例外を投げたときにこれを出します。InnerException を読み、EnableSensitiveDataLogging を有効にして、null チェックをラムダの外へ出してください。

EF Core 11 の UseSequence でキーを IDENTITY から SQL Server のシーケンスへ移す方法です。EF が実際に発行する SQL、明示的なキー値が IDENTITY_INSERT なしで通るようになる理由、int 列に bigint シーケンスをつないでしまう罠、そして設計時に見込んでおくべき欠番を扱います。

シングルトンは DbContext を注入できませんが、IDbContextFactory<T> なら注入できます。AddDbContextFactory がファクトリを既定でシングルトンとして登録するからです。呼び出しごとにコンテキストを生成して破棄し、インスタンスは決して保持しないでください。

.NET 10 SDK で dotnet tool install --global dotnet-ef が失敗するすべてのパターンを、正確なメッセージと終了コード付きで解説します。インストール済み、バージョンが見つからない、ダウングレード拒否、shim の衝突、到達できない NuGet フィード、そしてインストール成功後に初めて壊れるランタイム不一致。

プロシージャがエンティティの全列を返す場合は DbSet の FromSql、射影を返す場合は Database.SqlQuery<T>、何も返さない場合は ExecuteSql を使います。EXEC に LINQ 演算子を連結してはいけません。また、リーダーが破棄される前に出力パラメーターを読んではいけません。

テーブル名を変更した場合、EF Core は RenameTable を生成しますが、エンティティクラスの名前を変更した場合は DropTable と CreateTable を生成します。この2つを見分ける方法、クラス名変更のコストをゼロにする ToTable のテクニック、そしてデータを黙って入れ替えてしまう列名変更のバグを解説します。

ASP.NET Core の統合テストで確認する対象に応じて、HTTP ルーティング、本番データベース、発行済みアプリイメージのどこを実行するか選びます。

EF Core 11 に rowversion の同時実行トークンを追加します。[Timestamp] と IsRowVersion による設定、EF が実際に発行する SQL、DbUpdateConcurrencyException の捕捉、データベース優先 vs クライアント優先 vs マージ、ETag を使った切断された API、そして保護を無言で無効化する 5 つの落とし穴。

EF Core 11 で C# の enum を int ではなく読みやすい文字列として保存する方法です。HasConversion、すべての enum への一括設定、nvarchar(max) の罠、並び順の落とし穴、既存の int 列の移行手順を扱います。

Microsoft.EntityFrameworkCore.Design は DbContext を含むプロジェクトではなく、dotnet ef がビルドするスタートアッププロジェクトに追加し、階層化されたソリューションでは -s を渡します。

モデルが直近のマイグレーションのスナップショットと一致しないと EF Core は PendingModelChangesWarning を投げます。マイグレーションを追加するか、誤検知の原因を直します。

EF Core 11 のスキーマ変更をマイグレーション bundle でデプロイするための完全ガイドです。CI での efbundle のビルド、名前付き接続文字列における appsettings.json の落とし穴、self-contained bundle と Alpine の musl RID、EF Core 9 以降のマイグレーションロック、対象マイグレーションを指定したロールバック、そして MySQL ではマイグレーション単位のトランザクションが助けにならない理由を解説します。

EF Core 11 では、値オブジェクトにはデフォルトで複合型を使い、別テーブルが必要な場合や独自の行にマッピングされたコレクションが必要な場合にのみ所有エンティティに切り替えてください。

EF Core 11 では、ほぼすべての階層でデフォルトとして TPH を使い、単一のリーフ型をほぼ常にクエリしベンチマークで勝ると証明できる場合のみ TPC を選び、外部の制約に強いられる場合のみ TPT を使います。

この例外は、空のシーケンスに対して .First() や .Single() を呼び出したことを意味します。FirstOrDefault/SingleOrDefault で null をチェックするか、クエリをガードするか、ソースが空になる原因を修正します。

Entity Framework Core 11 がデータベースに送信する正確な SQL を、パラメーター値とともに、LogTo、Microsoft.Extensions.Logging、ToQueryString で確認します。

EF Core が保存方法を知らないプロパティに遭遇しました。complex type としてマッピングするか、HasConversion で変換するか、キーを与えるか、[NotMapped] で無視しましょう。

TPH は EF Core の既定の継承戦略です。1 つのテーブルと 1 つの識別子列を使います。識別子の構成、列の共有、派生型の null 許容プロパティの扱い、そして EF Core 11 での注意点を解説します。

所有エンティティは値オブジェクトと相性の悪い隠れたキーと参照同一性を持ちます。EF Core 11 で値オブジェクトを複合型としてマッピングする方法、切り替えるべきタイミング、そして注意点を解説します。

EF Core 11 でシードデータを HasData から UseSeeding と UseAsyncSeeding へ移す手順ガイド。見落とすと既存の行を削除してしまう DeleteData マイグレーションの落とし穴も含みます。

どちらも同じ SQL を生成します。名前付きフィルターに頼るのは、predicate を個別に無効化する必要があるときだけです。単一の関心事なら、EF Core 11 では 1 つに結合したフィルターの方がシンプルです。

EF Core 11 は、Where や OrderBy が SQL に変換できないメソッドを呼び出すとこれをスローします。予測を変換可能な演算子で書き直すか、先に AsEnumerable でデータをクライアントに取り込みましょう。

生の SQL がエンティティにマッピングされたすべての列を返さない、または名前が一致しないと EF Core はこの例外を投げます。一致する名前ですべてのマッピング列を返すか、スカラー型やキーレス型を照会してください。

EF Core 11 で同じエンティティに 2 つの独立したグローバルクエリフィルターを適用します。ソフト削除フィルターとテナントフィルターにそれぞれ名前を付け、IgnoreQueryFilters で一方だけを無効化できるようにします。

HasData は固定的でモデルが所有する参照データにのみ使います。EF Core 11 のそれ以外すべてには UseSeeding と UseAsyncSeeding を使います。判断を決定づけるルールとともに並べて比較します。

親にまだ依存行が残っており、データベースがそれらを孤立させることを拒否するため、EF Core は FOREIGN KEY constraint failed をスローします。子を読み込む、リレーションシップをオプションにする、または OnDelete を設定してください。

AddDbContext が実行されなかった、Build の後で実行された、またはコンテキストのコンストラクターが誤った DbContextOptions を受け取ると EF Core はこれをスローします。Build より前に登録し、DbContextOptions<YourContext> を使ってください。

HasData がストア生成キーのエンティティを明示的な値なしでシードしています。各行に安定したゼロ以外の Id を与えるか、生成キーには UseSeeding を使ってください。

Skip/Take を、最後に見た行の先までシークする WHERE 句に置き換えます。完全に一意なキーで並べ替え、最後の行の値をカーソルとして引き継げば、EF Core 11 は次のページを OFFSET スキャンではなくインデックスシークに変えてくれます。

ComplexProperty(...).ToJson() でネストした型を単一の JSON カラムにマッピングし、EF Core 11 に SQL Server 2025 のネイティブ json データ型で保存させ、JSON_VALUE・JSON_CONTAINS・JSON_PATH_EXISTS に変換される LINQ でクエリします。

EF Core 11 で多対多リレーションシップの結合テーブルにシードデータを投入する方法: 自分で名前を付ける必要がある暗黙のシャドウキー、UsingEntity と HasData のパターン、そしてスキップナビゲーションで動作する実行時の UseSeeding 代替手段。

EF Core 11 で UseSeeding と UseAsyncSeeding を使って参照データを正しくシードします。どこで設定するか、いつ実行されるか、省略できない冪等性チェック、そしてなぜ両方を実装する必要があるのかを解説します。

読み取り専用のクエリにはデフォルトで AsNoTracking を使います。結果のグラフが同じエンティティを複数回含み、かつコードが単一の共有インスタンスを受け取ることに依存している場合にのみ AsNoTrackingWithIdentityResolution を使います。

EF Core 11 Preview 5 には EF1004 アナライザーが含まれます。IQueryable に対する ToAsyncEnumerable() を指摘し、await foreach の中でデータベースクエリを誤って同期的に列挙しないようにします。

EF Core が型の主キーを見つけられません。プロパティを Id か {Type}Id と名付ける、[Key] を付ける、HasKey を呼ぶ、もしくはビューや生の SQL なら HasNoKey を呼びます。

EnableRetryOnFailure は BeginTransaction と競合します。トランザクション全体を db.Database.CreateExecutionStrategy().ExecuteAsync(...) でラップし、1 つの単位として再試行させます。

ISaveChangesInterceptor を使って EF Core 11 で CreatedBy/ModifiedOn 列をスタンプし、完全な変更履歴を記録します。DI のライフタイム、現在のユーザー、ExecuteUpdate の落とし穴も解説します。

EF Core 11 のための意思決定ガイドと実測ベンチマーク。述語による集合ベースの書き込みには ExecuteUpdate を使い、変更トラッカー、インターセプター、複雑なオブジェクトグラフが必要なときだけ読み込み→SaveChanges の経路を選びます。

EF Core 6.0 から EF Core 11.0 へのバージョン固定の移行ガイド。実際のアプリを壊す EF7、8、9、10、11 の破壊的変更を辿ります: Encrypt=True、OPENJSON による Contains、PendingModelChangesWarning、ネイティブ json 列、そして SqlClient 7.0 の分割。

fire-and-forget タスクが、DI スコープがすでに破棄したリクエストスコープの DbContext をキャプチャしました。IServiceScopeFactory または IDbContextFactory でタスク内に新しいコンテキストを解決してください。

EF Core 11 Preview 4 では dotnet ef ツールが .config/dotnet-ef.json ファイルからオプションの既定値を読み込めるようになり、分割されたソリューションでもすべてのコマンドで --project と --startup-project を渡す必要がなくなります。

2 つの同階層コレクションを Include すると、EF Core 11 はクロス積を返し、行数が爆発します。AsSplitQuery でこれをどう解決するか、グローバルに有効化する方法、そして注意すべき整合性と並び順の落とし穴を解説します。

EF Core 11 の ExecuteUpdate と ExecuteDelete の完全ガイド。生成される SQL、一括書き込みを静かに上書きしてしまう変更トラッカーの落とし穴、トランザクション、影響を受けた行数による同時実行制御、そして EF Core 10 のデリゲートセッターで単純な if 文を使って条件付き更新を組み立てる方法を解説します。

EF Core 11 Preview 4 で SQL Server テンポラルテーブルに対する長年の shadow プロパティ制約が撤廃されました。PeriodStart と PeriodEnd を通常の CLR プロパティとして宣言し、強く型付けされた HasPeriodStart と HasPeriodEnd のラムダで設定できます。

.NET 11 の読み取り中心のパスでは、AsNoTracking を付けた素の EF Core は Dapper の ~5% 以内に収まります。コンパイル済みクエリはプロファイル済みの単一行ホットパスで使い、Dapper は最小のレイテンシや LINQ で表現できない SQL のためだけに使いましょう。

3 つのシーケンスインターフェース、3 つの実行モデル。データベースがクエリを変換できる場合は IQueryable を、プロデューサーが非同期でストリーミングしたい場合は IAsyncEnumerable を、それ以外のメモリ内のものには IEnumerable を使用します。

.NET 11 での一括挿入では、EF Core も Dapper も勝ちません。SqlBulkCopy が勝ちます。これはそのベンチマークと理由、そして各ツールにふさわしい場所です。

System.Text.Json は逆参照を持つグラフのシリアライズを拒否します。ReferenceHandler.IgnoreCycles を設定するか、DTO に射影するか、逆向きポインタに [JsonIgnore] を付けてください。Preserve は最終手段です。

マイグレーションはランタイムの CommandTimeout ではなくデザインタイムの DbContext を使用します。UseSqlServer(o => o.CommandTimeout(...))、接続文字列の Command Timeout、または Migrate() の前の Database.SetCommandTimeout でタイムアウトを設定してください。

EF Core の設計時ツールが DbContext のインスタンスを作成できませんでした。WebApplication.CreateBuilder で host を公開するか、正しい startup project を指定するか、IDesignTimeDbContextFactory を実装してください。

EF Core 11 は、1 つの DbContext 内で 2 つのオブジェクトが主キーを共有するとこの例外をスローします。古い方をデタッチするか、その場で更新してください。読み取り側の AsNoTracking で衝突を防げます。

EF Core は同じ DbContext 上で 2 つの await が並行に実行されるとこの例外をスローします。各呼び出しを順次 await するか、IDbContextFactory で並行する作業単位ごとに新しい DbContext を取得してください。

.NET 11 で GetConnectionString が null を返す場合、appsettings.json にキーがない、ビルド出力にコピーされていない、または間違った環境ファイルが選ばれているかのいずれかです。3 つのチェックで 95% のケースが解決します。

EF Core 11 で N+1 クエリを見つけるための実践ガイドです。実際のコードで N+1 がどのように現れるか、ログ、診断インターセプター、OpenTelemetry を使ってどのように可視化するか、そしてホットパスがリグレッションしたときにビルドを壊すテストの書き方を解説します。

EF Core 11 のコンパイル済みクエリを実践的に解説します。EF.CompileAsyncQuery が本当に効くのはどんなときか、static フィールドのパターン、Include とトラッキングの落とし穴、追加の手間を払う価値があったと証明するためのビフォー／アフターのベンチマーク方法までを取り上げます。

Testcontainers 4.11 と EF Core 11 を使い、ASP.NET Core の統合テストを本物の SQL Server 2022 に対して実行するための完全ガイドです。WebApplicationFactory の組み立て、IAsyncLifetime、DbContext 登録の差し替え、マイグレーションの適用、並列実行、Ryuk によるクリーンアップ、CI のはまりどころを解説します。

EF Core は最初の DbContext アクセスで概念モデルを遅延構築するため、新しいプロセスでの最初のクエリは以後のどのクエリよりも数百ミリ秒遅くなります。本ガイドでは EF Core 11 で実用に足る三つの対策を扱います: Model に触れて接続を開く起動時の IHostedService、事前コンパイル済みモデルを出荷する dotnet ef dbcontext optimize、そして二つの対策を静かに無効化するキャッシュキーの落とし穴です。

DbContext を直接モックすると ChangeTracker が静かに壊れます。だからこそ Microsoft はそれを推奨していません。本ガイドは EF Core 11 で実際に機能する 2 つのパターンを示します。接続を開いたまま保持して本物の ChangeTracker を動かす SQLite インメモリと、テストから EF Core を完全に追い出すリポジトリパターンです。

EF Core 11 のクエリは IAsyncEnumerable<T> を直接実装しています。await foreach で行をストリーミングする方法、ToListAsync より好むべきタイミング、接続・トラッキング・キャンセルまわりの落とし穴。

C# の record と EF Core 11 を組み合わせる実践的なガイド。record がどこに収まり、どこで change tracking を壊すのか、そしてフレームワークと戦わずに value object、エンティティ、プロジェクションをモデリングする方法。

EF Core 11 Preview 3 は split query から冗長な to-one join を除去し、不要な ORDER BY キーを落とします。報告された一つのシナリオは 29% 速くなり、別のは 22% でした。今の SQL はこう見えます。

EF Core 11 Preview 3 は ChangeTracker.GetEntriesForState を導入します。state フィルターされた enumerator で、SaveChanges interceptor や audit hook のようなホットパスで余分な DetectChanges パスを避けます。

EF Core 11 は Cosmos DB の書き込みを SaveChanges ごとに container と partition 単位で transactional batch にグループ化し、コード変更なしで best-effort な原子性とラウンドトリップ削減を提供します。

dotnet ef database update コマンドが、マイグレーションを 1 つのステップでスキャフォールドして適用するための --add を受け入れるようになりました。仕組み、コンテナと .NET Aspire にとって重要な理由、注意点を紹介します。

EF Core 11 Preview 2 は SQL Server 2025 の VECTOR_SEARCH() と DiskANN ベクトルインデックスを LINQ から直接サポートします。インデックスのセットアップ、近似クエリの実行方法、EF Core 10 の VectorDistance アプローチからの変更点を紹介します。