LINQ

【C#】LINQとEntity Frameworkで実現するスマートなデータ挿入テクニック

2025-05-20更新日: 2025-05-20

LINQ自体にはInsert相当のメソッドがなく、コレクションへの追加はList.AddやInsert、データベースではEntity FrameworkのAddとSaveChangesで行います。

LINQは条件確認や重複チェックに使い、挿入ロジックはコレクションAPIまたはORMに委ねるのが基本です。

目次から探す

LINQとEntity Frameworkによる挿入の全体像
- LINQの役割
- Entity Frameworkを組み合わせる理由
挿入対象モデルの準備
- DbContextとエンティティ定義
単一レコード挿入のステップ
条件付き挿入
バルクインサート最適化
- AddRangeの性能特徴
- サードパーティライブラリによる高速化
トランザクション制御
- TransactionScopeの活用
- DbContext.Database.BeginTransaction
非同期挿入
- AddAsyncとSaveChangesAsync
- 同期とのパフォーマンス比較
複数テーブルへの一括挿入
- 親子関係エンティティ
- ナビゲーションプロパティの自動設定
エンティティ状態の理解
- EntityStateの種類
- 状態遷移の手動制御
例外処理
- DbUpdateException対策
- SQL制約違反時のリカバリ
パフォーマンス向上のコツ
- ChangeTrackerの自動検出無効化
- SaveChanges分割呼び出し
挿入とクエリの組み合わせ
- 挿入直後のID取得
- Selectでプロジェクション
よくある落とし穴
- Lazy Loadingによる意図しない挿入
- 循環参照問題とCascade Insert
セキュリティ上の注意
- SQLインジェクションを防ぐ
- 楽観的同時実行制御
まとめ

LINQとEntity Frameworkによる挿入の全体像

LINQの役割

LINQ(Language Integrated Query)は、C#に組み込まれた強力なクエリ機能で、コレクションやデータベースなどのデータソースに対して直感的にクエリを記述できます。

LINQの最大の特徴は、SQLのようなクエリ構文をC#のコード内で直接書けることにあります。

これにより、データの検索や並べ替え、集計などの読み取り操作が非常に簡単になります。

しかし、LINQは主に「読み取り中心」のAPIであるため、データの挿入や更新、削除といった書き込み操作は直接サポートしていません。

LINQはあくまでデータの抽出や変換に特化しているため、挿入操作を行う場合は別の手段と組み合わせる必要があります。

読み取り中心APIの制約

LINQの設計思想は、データのクエリ(問い合わせ)に特化しているため、以下のような制約があります。

挿入・更新・削除のメソッドが存在しない

LINQの標準APIには、AddやInsert、Update、Deleteといったデータの書き換えを行うメソッドは含まれていません。

LINQはあくまでWhereやSelect、OrderByなどの読み取り系メソッドが中心です。

不変性を前提とした操作

LINQのクエリは元のデータを変更せず、新しいシーケンスを返すことが多いです。

例えば、Selectで変換した結果は新しいコレクションとして返され、元のデータは変わりません。

データソースによっては書き込み操作が不可能

LINQ to Objects(メモリ内コレクション)では、元のコレクションに対して直接書き込み操作を行うことはできません。

LINQ to SQLやEntity FrameworkのようなORMでは、書き込み操作はORMのAPIを通じて行います。

このように、LINQは読み取りに特化しているため、挿入操作を行う際はLINQのクエリで条件を調べた後、別のAPIで実際の挿入処理を行うのが一般的です。

挿入を支援する典型パターン

LINQを使った挿入操作の典型的なパターンは、以下のような流れになります。

LINQで条件を検索する

まず、挿入対象のデータが既に存在するかどうかをAnyやWhere、FirstOrDefaultなどのLINQメソッドで調べます。

これにより、重複を防いだり、条件に合致するかを判定できます。

条件に応じて挿入処理を行う

検索結果をもとに、存在しなければ新しいデータを追加する処理を行います。

ここでの挿入は、LINQではなく、対象のデータソースに応じたAPI(例えば、List<T>.AddやEntity FrameworkのDbSet.Add)を使います。

変更の保存

データベースの場合は、SaveChangesやSaveChangesAsyncを呼び出して、変更を永続化します。

メモリ内コレクションの場合は、AddやInsertで即座に反映されます。

このパターンにより、LINQの強力な検索機能と、別のAPIによる挿入処理を組み合わせて効率的にデータ操作が可能です。

Entity Frameworkを組み合わせる理由

Entity Framework(EF)は、C#のオブジェクトとリレーショナルデータベースのテーブルをマッピングするORM(Object-Relational Mapping)ツールです。

EFを使うことで、データベースの操作をオブジェクト指向的に行え、SQL文を直接書かずにデータの挿入や更新、削除が可能になります。

LINQは読み取りに特化しているため、データの挿入や更新を行うにはEFのようなORMと組み合わせるのが一般的です。

EFはLINQクエリをサポートしているため、検索と挿入をシームレスに連携できます。

ORMとしての利点

Entity Frameworkを使うメリットは多岐にわたりますが、特に挿入操作に関しては以下の利点があります。

オブジェクト指向でデータ操作が可能

データベースのテーブルをC#のクラスとして扱い、インスタンスを作成してAddメソッドで追加するだけで挿入処理が完了します。

SQL文を意識せずに済むため、開発効率が向上します。

LINQクエリとの親和性が高い

EFはLINQ to Entitiesをサポートしており、LINQで条件検索を行い、その結果に基づいて挿入や更新を行うことが簡単にできます。

これにより、読み取りと書き込みの処理を統一的に記述できます。

トランザクション管理が容易

EFはSaveChanges呼び出し時にトランザクションを自動的に管理します。

複数の挿入や更新をまとめて安全に実行できるため、データの整合性を保ちやすいです。

変更追跡機能

EFはエンティティの状態を追跡し、どのオブジェクトが新規追加されたか、更新されたかを自動的に判別します。

これにより、AddやUpdateの呼び出しを明示的に行わなくても、SaveChangesで適切なSQLが生成されます。

マイグレーションやスキーマ管理のサポート

EFはデータベースのスキーマ変更をコードで管理できるマイグレーション機能を備えています。

これにより、開発中のテーブル構造の変更も容易に反映できます。

これらの利点により、LINQの読み取り機能とEFの書き込み機能を組み合わせることで、C#でのデータ操作が非常に効率的かつ安全に行えます。

特にデータベースへの挿入処理では、EFのAddメソッドとSaveChangesを使うことで、複雑なSQL文を書かずに済み、保守性の高いコードが実現できます。

挿入対象モデルの準備

DbContextとエンティティ定義

Entity Frameworkでデータの挿入を行うには、まずデータベースのテーブルに対応するエンティティクラスと、データベース接続や操作の窓口となるDbContextクラスを定義します。

DbContextはデータベースとのやり取りを管理し、エンティティはテーブルのレコードを表現します。

以下は、シンプルなProductエンティティと、それを管理するApplicationDbContextの例です。

using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }  // 主キー
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    // データベース接続の設定
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=SampleDb;Trusted_Connection=True;");
    }
}

この例では、Productクラスがテーブルの構造を表し、Idが主キーとなっています。

ApplicationDbContextのProductsプロパティは、Productエンティティの集合を表し、LINQクエリや挿入操作の対象となります。

Data Annotationの基本

エンティティのプロパティに対して属性(Attribute)を付与することで、データベースのスキーマや制約を細かく指定できます。

これをData Annotationと呼びます。

主に以下のような属性がよく使われます。

属性名	説明	例
`[Key]`	主キーを指定	`public int Id { get; set; }`に付与
`[Required]`	NULL禁止(必須項目)	`public string Name { get; set; }`に付与
`[MaxLength(n)]`	文字列の最大長を指定	`[MaxLength(100)] public string Name { get; set; }`
`[Column("ColumnName")]`	データベースのカラム名を指定	`[Column("product_name")] public string Name { get; set; }`

例えば、ProductクラスにData Annotationを付けると以下のようになります。

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
public class Product
{
    [Key]
    public int Id { get; set; }
    [Required]
    [MaxLength(100)]
    public string Name { get; set; }
    [Column("unit_price")]
    public decimal Price { get; set; }
}

このように指定すると、Nameは必須で最大100文字、Priceはデータベース上でunit_priceというカラム名になります。

Data Annotationは簡潔に制約を指定できるため、小規模なモデル定義に適しています。

Fluent APIの応用

Data Annotationでは対応しきれない複雑な設定や、コードの分離を図りたい場合は、DbContextのOnModelCreatingメソッド内でFluent APIを使って設定します。

Fluent APIはメソッドチェーンで柔軟にモデルの構成を記述でき、以下のような設定が可能です。

複合主キーの指定
テーブル名やカラム名の変更
リレーションシップの定義(1対多、多対多など)
インデックスの作成
デフォルト値や制約の指定

例として、Productエンティティの設定をFluent APIで行う場合は以下のようになります。

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Product>(entity =>
    {
        entity.ToTable("ProductsTable");  // テーブル名を変更
        entity.HasKey(e => e.Id);         // 主キー指定
        entity.Property(e => e.Name)
            .IsRequired()                 // 必須
            .HasMaxLength(100)            // 最大長100
            .HasColumnName("product_name"); // カラム名変更
        entity.Property(e => e.Price)
            .HasColumnType("decimal(18,2)") // データ型指定
            .HasDefaultValue(0);              // デフォルト値
    });
}

Fluent APIはData Annotationよりも詳細な設定が可能で、特に大規模なプロジェクトや複雑なデータベース設計に向いています。

OnModelCreating内にまとめて設定できるため、モデルクラスがシンプルに保てるのもメリットです。

単一レコード挿入のステップ

コンテキスト生成

Entity Frameworkでデータベースにデータを挿入する際は、まずDbContextのインスタンスを生成します。

DbContextはデータベースとの接続や操作を管理するクラスで、これを通じてエンティティの追加や変更を行います。

DbContextの生成は通常、usingステートメントを使ってスコープを限定し、処理終了後にリソースを解放する形で行います。

以下はApplicationDbContextのインスタンスを生成する例です。

using (var context = new ApplicationDbContext())
{
    // ここでデータ操作を行う
}

このようにすることで、contextのライフサイクルが明確になり、接続の開放やメモリ管理が適切に行われます。

DbContextはスレッドセーフではないため、複数スレッドで共有せず、必要に応じて都度生成するのが推奨されます。

エンティティ作成

挿入したいデータを表すエンティティオブジェクトを作成します。

エンティティはDbContextのDbSetに対応するクラスで、プロパティに値をセットして新しいレコードの内容を定義します。

例えば、Productエンティティに新しい製品情報をセットする場合は以下のようになります。

var newProduct = new Product
{
    Name = "Sample Product",
    Price = 29.99m
};

ここで注意したいのは、主キー(例えばId)は通常自動生成されるため、明示的に設定しないことが多い点です。

主キーの生成方法はデータベースの設定やエンティティの属性によって異なりますが、Identity列やGUID生成などが一般的です。

AddとSaveChangesの呼び出し

エンティティを作成したら、DbContextのDbSetに対してAddメソッドを呼び出し、挿入対象としてマークします。

これにより、EFの変更追跡機能が新規追加の状態を認識します。

context.Products.Add(newProduct);

ただし、この時点ではまだデータベースには反映されていません。

実際にデータベースに挿入するには、SaveChangesメソッドを呼び出して変更を確定させます。

context.SaveChanges();

SaveChangesは、DbContextが追跡しているすべての変更(追加・更新・削除)をデータベースに反映します。

単一の挿入であっても必ず呼び出す必要があります。

以下に、これらのステップをまとめたサンプルコードを示します。

using System;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("TestDb");
    }
}
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            // 新しい製品エンティティを作成
            var newProduct = new Product
            {
                Name = "Sample Product",
                Price = 29.99m
            };
            // DbSetに追加
            context.Products.Add(newProduct);
            // 変更をデータベースに保存
            context.SaveChanges();
            // 挿入結果の確認
            foreach (var product in context.Products)
            {
                Console.WriteLine($"Id: {product.Id}, Name: {product.Name}, Price: {product.Price}");
            }
        }
    }
}

Id: 1, Name: Sample Product, Price: 29.99

このコードでは、InMemoryDatabaseを使って簡易的にデータベースを模擬しています。

Addでエンティティを追加し、SaveChangesで確定した後、Productsテーブルの内容を表示しています。

Idは自動的に1から割り当てられていることがわかります。

条件付き挿入

Anyでの重複確認

データベースに新しいレコードを挿入する際、同じ条件のデータが既に存在しないかを確認することは重要です。

Entity Frameworkでは、LINQのAnyメソッドを使って簡単に重複チェックができます。

Anyは、指定した条件に合致するレコードが1件でも存在すればtrueを返し、存在しなければfalseを返します。

これを利用して、重複がなければ挿入処理を行うロジックを組み立てられます。

以下は、Productテーブルに同じ名前の製品が存在しない場合のみ新規挿入する例です。

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("TestDb");
    }
}
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            string newProductName = "Unique Product";
            // 重複チェック
            bool exists = context.Products.Any(p => p.Name == newProductName);
            if (!exists)
            {
                var newProduct = new Product
                {
                    Name = newProductName,
                    Price = 49.99m
                };
                context.Products.Add(newProduct);
                context.SaveChanges();
                Console.WriteLine($"Product '{newProductName}' was added.");
            }
            else
            {
                Console.WriteLine($"Product '{newProductName}' already exists.");
            }
        }
    }
}

Product 'Unique Product' was added.

このコードでは、Anyで名前が一致する製品があるかを判定し、なければ追加しています。

Anyは効率的に存在チェックができるため、重複防止に最適です。

Where＋Countでの存在チェック

Anyの代わりに、Whereで条件を絞り込み、Countで件数を取得して存在を確認する方法もあります。

Countが0より大きければ該当データが存在すると判断できます。

以下は同様の重複チェックをWhere＋Countで行う例です。

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            string newProductName = "Another Product";
            int count = context.Products.Where(p => p.Name == newProductName).Count();
            if (count == 0)
            {
                var newProduct = new Product
                {
                    Name = newProductName,
                    Price = 59.99m
                };
                context.Products.Add(newProduct);
                context.SaveChanges();
                Console.WriteLine($"Product '{newProductName}' was added.");
            }
            else
            {
                Console.WriteLine($"Product '{newProductName}' already exists.");
            }
        }
    }
}

Product 'Another Product' was added.

Where＋CountはAnyよりも少し冗長ですが、条件に合致する件数を知りたい場合に便利です。

ただし、存在チェックだけならAnyのほうがパフォーマンス面で優れています。

挿入の実行と結果確認

条件付き挿入の最後のステップは、条件を満たした場合に実際にデータを挿入し、その結果を確認することです。

Addメソッドでエンティティを追加し、SaveChangesでデータベースに反映します。

挿入後は、挿入したデータが正しく保存されたかを確認するために、再度クエリを実行して結果を取得することが多いです。

以下は、条件付き挿入後に全製品を一覧表示する例です。

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            string productName = "Conditional Product";
            if (!context.Products.Any(p => p.Name == productName))
            {
                var product = new Product
                {
                    Name = productName,
                    Price = 39.99m
                };
                context.Products.Add(product);
                context.SaveChanges();
                Console.WriteLine($"Product '{productName}' inserted.");
            }
            else
            {
                Console.WriteLine($"Product '{productName}' already exists.");
            }
            // 挿入後の全製品を表示
            var allProducts = context.Products.ToList();
            Console.WriteLine("Current products in database:");
            foreach (var p in allProducts)
            {
                Console.WriteLine($"Id: {p.Id}, Name: {p.Name}, Price: {p.Price}");
            }
        }
    }
}

Product 'Conditional Product' inserted.
Current products in database:
Id: 1, Name: Conditional Product, Price: 39.99

このように、条件付き挿入では存在チェックを行い、問題なければAddとSaveChangesで挿入し、その後にデータを取得して結果を確認する流れが基本です。

これにより、重複を防ぎつつ安全にデータを追加できます。

バルクインサート最適化

AddRangeの性能特徴

Entity Frameworkで複数のレコードを一括で挿入する場合、DbSetのAddRangeメソッドを使うことが一般的です。

AddRangeは複数のエンティティをまとめて追加対象としてマークし、SaveChangesの呼び出し時に一括でデータベースに反映されます。

using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("BulkInsertDb");
    }
}
class Program
{
    static void Main()
    {
        var products = new List<Product>
        {
            new Product { Name = "Product A", Price = 10.0m },
            new Product { Name = "Product B", Price = 20.0m },
            new Product { Name = "Product C", Price = 30.0m }
        };
        using (var context = new ApplicationDbContext())
        {
            context.Products.AddRange(products);
            context.SaveChanges();
            foreach (var product in context.Products)
            {
                Console.WriteLine($"Id: {product.Id}, Name: {product.Name}, Price: {product.Price}");
            }
        }
    }
}

Id: 1, Name: Product A, Price: 10.0
Id: 2, Name: Product B, Price: 20.0
Id: 3, Name: Product C, Price: 30.0

AddRangeは単一のAddを複数回呼ぶよりも効率的で、内部的に複数のエンティティをまとめて処理します。

ただし、SaveChangesは依然として1回のトランザクションで全ての挿入を行うため、データ量が非常に多い場合はパフォーマンスに影響が出ることがあります。

また、AddRangeはエンティティの状態を一括でAddedに設定し、変更追跡を行います。

大量のデータを扱う際は、ChangeTracker.AutoDetectChangesEnabledを一時的に無効化することでパフォーマンスを改善できる場合があります。

context.ChangeTracker.AutoDetectChangesEnabled = false;
context.Products.AddRange(products);
context.ChangeTracker.AutoDetectChangesEnabled = true;
context.SaveChanges();

この設定により、AddRange中の変更検出処理が省略され、挿入処理が高速化されます。

ただし、変更検出を無効にする間は、エンティティの状態管理に注意が必要です。

サードパーティライブラリによる高速化

Entity Frameworkの標準機能では大量データのバルクインサートに限界があるため、パフォーマンスを大幅に向上させるためにサードパーティ製のライブラリを利用するケースが多いです。

代表的なものに以下があります。

ライブラリ名	特徴
EFCore.BulkExtensions	EF Core対応の高速バルク操作ライブラリ。Insert、Update、Delete、Mergeをサポート。
Z.EntityFramework.Extensions	高機能で商用利用も可能です。バルクインサートやバルクアップデートに対応。

これらのライブラリは、SQLのBULK INSERTやMERGE文を内部で利用し、通常のAddRange＋SaveChangesよりも数倍から数十倍高速に大量データを挿入できます。

EFCore.BulkExtensionsの簡単な使用例を示します。

using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;
using EFCore.BulkExtensions;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("YourConnectionStringHere");
    }
}
class Program
{
    static void Main()
    {
        var products = new List<Product>();
        for (int i = 1; i <= 10000; i++)
        {
            products.Add(new Product { Name = $"Product {i}", Price = i });
        }
        using (var context = new ApplicationDbContext())
        {
            context.BulkInsert(products);
            Console.WriteLine("Bulk insert completed.");
        }
    }
}

このコードでは、1万件のProductを一括で高速に挿入しています。

BulkInsertは大量データの挿入に特化しており、通常のAddRange＋SaveChangesよりも大幅に高速です。

ただし、サードパーティライブラリを使う際は以下の点に注意してください。

依存関係の追加

NuGetからライブラリをインストールする必要があります。

データベースの種類に依存

一部の機能はSQL Serverなど特定のDBに最適化されています。

トランザクション管理

バルク操作はトランザクションの扱いが異なる場合があるため、注意が必要です。

マイグレーションや変更追跡との併用

バルク操作はEFの変更追跡をバイパスすることが多いため、状態管理に注意が必要です。

これらを踏まえ、パフォーマンスが重要な大量データの挿入には、AddRangeの基本的な使い方を理解した上で、必要に応じてサードパーティ製のバルクインサートライブラリを活用すると良いでしょう。

トランザクション制御

TransactionScopeの活用

複数のデータベース操作を一つのトランザクションとしてまとめて実行し、すべて成功した場合のみ確定させるために、TransactionScopeを利用できます。

TransactionScopeは.NETのトランザクション管理機能で、複数のDbContextや異なるリソースをまたぐトランザクションも扱えます。

TransactionScopeを使う場合は、usingブロック内に処理を記述し、すべての操作が成功したらCompleteメソッドを呼び出してトランザクションをコミットします。

Completeが呼ばれなければ、スコープ終了時に自動的にロールバックされます。

以下はTransactionScopeを使った例です。

using System;
using System.Transactions;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("TransactionScopeDb");
    }
}
class Program
{
    static void Main()
    {
        using (var scope = new TransactionScope())
        {
            using (var context = new ApplicationDbContext())
            {
                var product1 = new Product { Name = "Product 1", Price = 10m };
                context.Products.Add(product1);
                context.SaveChanges();
            }
            using (var context = new ApplicationDbContext())
            {
                var product2 = new Product { Name = "Product 2", Price = 20m };
                context.Products.Add(product2);
                context.SaveChanges();
            }
            // すべての操作が成功したのでコミット
            scope.Complete();
        }
        // 挿入結果の確認
        using (var context = new ApplicationDbContext())
        {
            foreach (var product in context.Products)
            {
                Console.WriteLine($"Id: {product.Id}, Name: {product.Name}, Price: {product.Price}");
            }
        }
    }
}

Id: 1, Name: Product 1, Price: 10
Id: 2, Name: Product 2, Price: 20

この例では、2つのDbContextインスタンスで別々にデータを追加していますが、TransactionScopeにより両方の操作が一つのトランザクションとして扱われます。

Completeが呼ばれなければ、どちらかの操作が失敗した場合に全体がロールバックされます。

注意点として、TransactionScopeは分散トランザクションを扱うため、環境によってはMSDTC(Microsoft Distributed Transaction Coordinator)の設定が必要になる場合があります。

また、非同期処理で使う場合はTransactionScopeAsyncFlowOption.Enabledを指定する必要があります。

DbContext.Database.BeginTransaction

DbContextにはDatabaseプロパティがあり、その中のBeginTransactionメソッドを使ってトランザクションを開始できます。

こちらは単一のDbContext内でのトランザクション制御に適しており、より細かい制御が可能です。

BeginTransactionはIDbContextTransactionを返し、usingブロックで囲んでトランザクションのスコープを管理します。

処理が成功したらCommitを呼び、失敗時はDispose時にロールバックされます。

以下はBeginTransactionを使った例です。

using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Storage;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("BeginTransactionDb");
    }
}
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            using (IDbContextTransaction transaction = context.Database.BeginTransaction())
            {
                try
                {
                    var product1 = new Product { Name = "Product A", Price = 15m };
                    context.Products.Add(product1);
                    context.SaveChanges();
                    var product2 = new Product { Name = "Product B", Price = 25m };
                    context.Products.Add(product2);
                    context.SaveChanges();
                    // すべて成功したのでコミット
                    transaction.Commit();
                }
                catch (Exception ex)
                {
                    Console.WriteLine($"Error occurred: {ex.Message}");
                    // ロールバックはDispose時に自動で行われる
                }
            }
            // 挿入結果の確認
            foreach (var product in context.Products)
            {
                Console.WriteLine($"Id: {product.Id}, Name: {product.Name}, Price: {product.Price}");
            }
        }
    }
}

Id: 1, Name: Product A, Price: 15
Id: 2, Name: Product B, Price: 25

この方法は単一のDbContext内で複数の操作をまとめてトランザクション管理したい場合に便利です。

BeginTransactionは明示的にコミットしなければロールバックされるため、例外発生時の安全性が高いです。

TransactionScopeと比べて、BeginTransactionはより軽量で単純なトランザクション制御に向いていますが、複数のDbContextや異なるリソースをまたぐ場合はTransactionScopeのほうが適しています。

用途に応じて使い分けると良いでしょう。

非同期挿入

AddAsyncとSaveChangesAsync

Entity Framework Coreでは、非同期処理を活用してデータベースへの挿入操作を効率的に行うことができます。

特にAddAsyncとSaveChangesAsyncは、非同期でエンティティの追加と変更の保存を行うメソッドです。

これらを使うことで、UIスレッドのブロックを防ぎ、スケーラブルなアプリケーションを構築しやすくなります。

AddAsyncはDbSetに新しいエンティティを非同期で追加します。

内部的には、エンティティの状態をAddedに設定する処理が非同期で行われます。

AddAsyncは主に非同期ストリームや大規模なデータ挿入時に効果を発揮しますが、単純なメモリ操作のため、通常のAddと大きな違いはありません。

一方、SaveChangesAsyncはSaveChangesの非同期版で、データベースへの変更を非同期に反映します。

データベースへの通信が非同期で行われるため、待機時間中に他の処理を進められます。

以下はAddAsyncとSaveChangesAsyncを使った非同期挿入のサンプルコードです。

using System;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("AsyncInsertDb");
    }
}
class Program
{
    static async Task Main()
    {
        using (var context = new ApplicationDbContext())
        {
            var newProduct = new Product
            {
                Name = "Async Product",
                Price = 99.99m
            };
            await context.Products.AddAsync(newProduct);
            await context.SaveChangesAsync();
            var products = await context.Products.ToListAsync();
            foreach (var product in products)
            {
                Console.WriteLine($"Id: {product.Id}, Name: {product.Name}, Price: {product.Price}");
            }
        }
    }
}

Id: 1, Name: Async Product, Price: 99.99

このコードでは、AddAsyncでエンティティを追加し、SaveChangesAsyncで非同期にデータベースへ保存しています。

Mainメソッドはasync Taskとして定義し、awaitを使って非同期処理を待機しています。

同期とのパフォーマンス比較

非同期挿入は、特にI/O待ちが発生するデータベース操作において、アプリケーションの応答性やスループットを向上させる効果があります。

同期処理では、データベースへの通信が完了するまでスレッドがブロックされるため、UIが固まったり、サーバーのスレッドプールが枯渇したりするリスクがあります。

一方、非同期処理はスレッドを解放しつつ待機できるため、他のリクエストや処理を並行して実行可能です。

これにより、特にWebアプリケーションや高負荷環境でのパフォーマンスが向上します。

ただし、単純なコンソールアプリケーションや小規模な処理では、非同期処理のオーバーヘッドがわずかに増えることもあります。

AddAsync自体は内部的にほぼ同期的な処理であるため、Addとの違いはほとんどありません。

主なパフォーマンス差はSaveChangesとSaveChangesAsyncの間にあります。

以下は簡単な比較ポイントです。

項目	同期処理 `(Add` + `SaveChanges)`	非同期処理 `(AddAsync` + `SaveChangesAsync)`
スレッドブロック	あり	なし(待機中にスレッド解放)
UI応答性	低下する可能性あり	高い
サーバーのスループット	限定的	向上
実装の複雑さ	シンプル	`async/await`の理解が必要
オーバーヘッド	低い	わずかに高い

まとめると、非同期挿入は特にWebアプリケーションや高負荷環境で効果的であり、UIの応答性やスケーラビリティを向上させます。

同期処理は単純で扱いやすいですが、スレッドのブロックによるパフォーマンス低下のリスクがあります。

用途に応じて使い分けることが重要です。

複数テーブルへの一括挿入

親子関係エンティティ

Entity Frameworkでは、複数のテーブルにまたがる親子関係のデータを一括で挿入することが可能です。

親エンティティと子エンティティの関係を正しくモデル化し、親子のオブジェクトを作成してからDbContextに追加すれば、EFが自動的に関連するテーブルに対して適切な挿入処理を行います。

例えば、Order(注文)とOrderItem(注文詳細)の親子関係を考えます。

Orderが親で、複数のOrderItemを持つ構造です。

public class Order
{
    public int Id { get; set; }
    public DateTime OrderDate { get; set; }
    // 子エンティティのコレクション
    public List<OrderItem> OrderItems { get; set; } = new List<OrderItem>();
}
public class OrderItem
{
    public int Id { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
    // 親エンティティの外部キー
    public int OrderId { get; set; }
    public Order Order { get; set; }
}

このように親子関係を表現したエンティティを用意し、親エンティティのOrderItemsコレクションに子エンティティを追加します。

次に、親エンティティをDbContextに追加し、SaveChangesを呼ぶだけで、親テーブルと子テーブルの両方にデータが挿入されます。

using (var context = new ApplicationDbContext())
{
    var order = new Order
    {
        OrderDate = DateTime.Now,
        OrderItems = new List<OrderItem>
        {
            new OrderItem { ProductName = "Product A", Quantity = 2 },
            new OrderItem { ProductName = "Product B", Quantity = 1 }
        }
    };
    context.Orders.Add(order);
    context.SaveChanges();
}

このコードでは、orderオブジェクトを追加するだけで、EFがOrderテーブルとOrderItemテーブルに対して適切なINSERT文を発行し、親子関係を保ったままデータを保存します。

ナビゲーションプロパティの自動設定

Entity Frameworkは、親子関係のナビゲーションプロパティを通じて、関連するエンティティの外部キーや参照を自動的に設定します。

これにより、開発者は外部キーを明示的に設定しなくても、オブジェクトの関係性を正しく保てます。

上記のOrderとOrderItemの例でいうと、OrderItemのOrderプロパティに親のOrderオブジェクトをセットするか、親のOrderItemsコレクションに子のOrderItemを追加するだけで、EFはOrderIdの外部キーを自動的に設定します。

例えば、以下の2つのコードはどちらも同じ結果をもたらします。

// パターン1: 親のコレクションに子を追加
var order = new Order { OrderDate = DateTime.Now };
var item = new OrderItem { ProductName = "Product C", Quantity = 3 };
order.OrderItems.Add(item);
context.Orders.Add(order);
context.SaveChanges();

// パターン2: 子の親プロパティに親をセット
var order = new Order { OrderDate = DateTime.Now };
var item = new OrderItem { ProductName = "Product C", Quantity = 3, Order = order };
context.OrderItems.Add(item);
context.SaveChanges();

どちらの方法でも、EFはOrderItemのOrderIdを正しく設定し、親子関係を維持したままデータを挿入します。

この自動設定は、EFの変更追跡機能とナビゲーションプロパティの連携によって実現されており、外部キーの手動設定ミスを防ぎ、コードの可読性と保守性を高めます。

まとめると、複数テーブルへの一括挿入では、親子関係のエンティティを正しくモデル化し、ナビゲーションプロパティを活用してオブジェクトの関係を構築することで、EFが自動的に関連テーブルに対して挿入処理を行い、整合性のあるデータ保存が可能になります。

エンティティ状態の理解

EntityStateの種類

Entity Frameworkでは、エンティティの状態を管理するためにEntityStateという列挙型が用意されています。

EntityStateは、DbContextの変更追跡機能がエンティティの現在の状態を把握し、適切なデータベース操作(挿入、更新、削除など)を行うために使われます。

主なEntityStateの種類は以下の通りです。

EntityState	説明
`Detached`	エンティティが`DbContext`に追跡されていない状態。データベースとの関連がない状態です。
`Unchanged`	エンティティが`DbContext`に追跡されており、データベースの値と同期している状態。
`Added`	新規に追加されたエンティティで、`SaveChanges`時にINSERT文が発行される状態。
`Modified`	既存のエンティティが変更されており、`SaveChanges`時にUPDATE文が発行される状態。
`Deleted`	削除対象のエンティティで、`SaveChanges`時にDELETE文が発行される状態。

例えば、新しいエンティティをAddメソッドで追加すると、そのエンティティの状態はAddedになります。

SaveChangesを呼ぶと、EFはAdded状態のエンティティに対してINSERT文を発行し、データベースに新規レコードを作成します。

逆に、データベースから取得したエンティティは初期状態でUnchangedとなり、プロパティを変更するとModifiedに変わります。

Removeメソッドを呼ぶとDeleted状態になります。

状態遷移の手動制御

通常、AddやRemove、Updateなどのメソッドを使うことでエンティティの状態は自動的に変更されますが、場合によっては手動で状態を設定したいことがあります。

DbContext.Entryメソッドを使うと、特定のエンティティの状態を明示的に変更できます。

using (var context = new ApplicationDbContext())
{
    var product = new Product { Id = 1, Name = "Updated Product", Price = 50m };
    // エンティティをDbContextにアタッチ(追跡開始)
    context.Products.Attach(product);
    // 状態をModifiedに設定し、更新対象とする
    context.Entry(product).State = EntityState.Modified;
    context.SaveChanges();
}

この例では、productは新規作成したオブジェクトで、まだDbContextは追跡していません。

Attachで追跡を開始し、StateをModifiedに設定することで、SaveChanges時にUPDATE文が発行されます。

また、Detached状態に設定すると、DbContextの追跡対象から外れ、変更が反映されなくなります。

context.Entry(product).State = EntityState.Detached;

状態遷移を手動で制御することで、例えば外部から取得したエンティティを更新対象として扱ったり、追跡を解除してパフォーマンスを最適化したりすることが可能です。

ただし、状態管理を誤ると意図しないデータベース操作が発生することがあるため、状態遷移の手動制御は慎重に行う必要があります。

特に複雑なシナリオでは、状態の確認やログ出力を活用して動作を把握すると良いでしょう。

例外処理

DbUpdateException対策

Entity Frameworkでデータベースへの挿入や更新を行う際、SaveChangesやSaveChangesAsyncの呼び出し時にDbUpdateExceptionが発生することがあります。

これは、データベースの制約違反や接続エラーなど、更新処理に失敗した場合にスローされる例外です。

DbUpdateExceptionはEFの内部例外であり、実際の原因はInnerExceptionに格納されていることが多いため、例外処理時にはInnerExceptionの内容を確認することが重要です。

以下はDbUpdateExceptionをキャッチして適切に対処する例です。

using System;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        try
        {
            using (var context = new ApplicationDbContext())
            {
                var product = new Product
                {
                    // 例えば、NameがNULL禁止のカラムにNULLを設定した場合など
                    Name = null,
                    Price = 10m
                };
                context.Products.Add(product);
                context.SaveChanges();
            }
        }
        catch (DbUpdateException ex)
        {
            Console.WriteLine("データベース更新時にエラーが発生しました。");
            if (ex.InnerException != null)
            {
                Console.WriteLine($"詳細: {ex.InnerException.Message}");
            }
            else
            {
                Console.WriteLine(ex.Message);
            }
            // ログ記録やリトライ処理などの対応をここに記述
        }
    }
}

このように、DbUpdateExceptionを捕捉してエラーメッセージをログに出力したり、ユーザーに通知したりすることが基本的な対策です。

原因に応じてリトライや代替処理を実装することもあります。

SQL制約違反時のリカバリ

データベースの制約違反(例えば、主キー重複、外部キー制約違反、一意制約違反、NULL禁止カラムへのNULL挿入など)が原因でDbUpdateExceptionが発生した場合、適切なリカバリ処理を行うことが重要です。

リカバリの方法はケースバイケースですが、代表的な対応例を紹介します。

重複データの検出とスキップ

一意制約違反が発生した場合、既に同じデータが存在する可能性が高いため、挿入をスキップするか、更新に切り替える処理を行います。

try
{
    context.SaveChanges();
}
catch (DbUpdateException ex) when (IsUniqueConstraintViolation(ex))
{
    Console.WriteLine("重複データのため挿入をスキップします。");
    // 必要に応じて更新処理に切り替えたり、ログを残したりする
}

IsUniqueConstraintViolationは例外の内容を解析して一意制約違反かどうかを判定するカスタムメソッドです。

SQL Serverや他のDBMSごとにエラーコードが異なるため、適切に実装します。

外部キー制約違反の対応

外部キー制約違反は、関連する親データが存在しない場合に発生します。

リカバリとしては、親データの存在を事前に確認し、なければ挿入するか、エラーをユーザーに通知します。

bool parentExists = context.Parents.Any(p => p.Id == child.ParentId);
if (!parentExists)
{
    Console.WriteLine("親データが存在しません。挿入を中止します。");
    // 代替処理やエラーメッセージ表示
}
else
{
    context.SaveChanges();
}

NULL禁止カラムへのNULL挿入防止

エンティティのプロパティに[Required]属性を付けたり、ビジネスロジックでNULLチェックを行うことで、NULL禁止カラムへの不正な値の挿入を防ぎます。

if (string.IsNullOrEmpty(product.Name))
{
    Console.WriteLine("製品名は必須です。");
    return;
}
context.SaveChanges();

トランザクションを使ったロールバック

複数の挿入や更新をまとめて行う場合は、トランザクションを利用して一連の処理がすべて成功した場合のみコミットし、失敗時はロールバックして整合性を保ちます。

using (var transaction = context.Database.BeginTransaction())
{
    try
    {
        context.SaveChanges();
        transaction.Commit();
    }
    catch (DbUpdateException)
    {
        transaction.Rollback();
        throw;
    }
}

これらの対策を組み合わせることで、DbUpdateExceptionやSQL制約違反時のエラーを適切にハンドリングし、アプリケーションの安定性とデータ整合性を確保できます。

エラーの内容に応じてユーザーへのフィードバックやログ記録を行い、必要に応じてリトライや代替処理を実装することが望ましいです。

パフォーマンス向上のコツ

ChangeTrackerの自動検出無効化

Entity FrameworkのChangeTrackerは、DbContextが管理するエンティティの状態変化を自動的に検出し、SaveChanges時に適切なSQLを生成する重要な機能です。

しかし、大量のエンティティを扱う場合、この自動検出処理がパフォーマンスのボトルネックになることがあります。

ChangeTracker.AutoDetectChangesEnabledプロパティをfalseに設定すると、自動検出を無効化できます。

これにより、AddやUpdateなどの操作時に状態検出が行われなくなり、処理が高速化されます。

ただし、自動検出を無効にした場合は、明示的にChangeTracker.DetectChanges()を呼び出して状態を更新する必要があります。

以下は自動検出を無効化して大量データを追加する例です。

using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        var products = new List<Product>();
        for (int i = 0; i < 10000; i++)
        {
            products.Add(new Product { Name = $"Product {i}", Price = i });
        }
        using (var context = new ApplicationDbContext())
        {
            // 自動検出を無効化
            context.ChangeTracker.AutoDetectChangesEnabled = false;
            context.Products.AddRange(products);
            // 必要に応じて手動で検出
            context.ChangeTracker.DetectChanges();
            context.SaveChanges();
            // 自動検出を再度有効化
            context.ChangeTracker.AutoDetectChangesEnabled = true;
        }
    }
}

この方法により、AddRange時の状態検出コストを削減し、大量データの挿入が高速化されます。

ただし、自動検出を無効にしている間は、エンティティの状態が正しく追跡されないため、状態変更の反映漏れに注意が必要です。

SaveChanges分割呼び出し

大量のデータを一度にSaveChangesで保存すると、トランザクションのサイズが大きくなり、メモリ消費やデータベース負荷が増大します。

これにより、パフォーマンス低下やタイムアウトの原因になることがあります。

この問題を回避するために、挿入対象のエンティティを適切なサイズのバッチに分割し、複数回に分けてSaveChangesを呼び出す方法が有効です。

バッチサイズは環境やデータ量に応じて調整しますが、一般的には数百件から数千件程度が目安です。

以下はバッチ処理でSaveChangesを分割呼び出しする例です。

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        var products = new List<Product>();
        for (int i = 0; i < 5000; i++)
        {
            products.Add(new Product { Name = $"Product {i}", Price = i });
        }
        int batchSize = 1000;
        using (var context = new ApplicationDbContext())
        {
            for (int i = 0; i < products.Count; i += batchSize)
            {
                var batch = products.Skip(i).Take(batchSize).ToList();
                context.Products.AddRange(batch);
                context.SaveChanges();
                // 追加したエンティティをコンテキストから切り離すことでメモリ消費を抑制
                foreach (var entity in batch)
                {
                    context.Entry(entity).State = EntityState.Detached;
                }
            }
        }
    }
}

このコードでは、5000件のProductを1000件ずつに分割して挿入しています。

SaveChangesを複数回呼ぶことで、一度のトランザクションが小さくなり、データベースやアプリケーションの負荷を軽減できます。

また、EntityState.Detachedに設定してエンティティをDbContextの追跡対象から外すことで、メモリ使用量の増加を防止しています。

これにより、長時間の大量データ処理でも安定したパフォーマンスを維持できます。

これらのテクニックを組み合わせることで、Entity Frameworkでの大量データ挿入時のパフォーマンスを大幅に向上させることが可能です。

特に大量データを扱うバッチ処理やバックグラウンドジョブでは、ChangeTrackerの自動検出無効化とSaveChangesの分割呼び出しを積極的に活用すると良いでしょう。

挿入とクエリの組み合わせ

挿入直後のID取得

Entity Frameworkで新しいエンティティをデータベースに挿入した後、そのエンティティの自動生成された主キー(ID)を取得することはよくある要件です。

EFはSaveChangesやSaveChangesAsyncを呼び出したタイミングで、データベースから生成されたIDをエンティティのプロパティに自動的にセットします。

例えば、ProductエンティティのIdがデータベースで自動採番される場合、以下のように挿入後にIDを取得できます。

using System;
using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }  // 自動採番される主キー
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("InsertIdDb");
    }
}
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            var newProduct = new Product
            {
                Name = "New Product",
                Price = 19.99m
            };
            context.Products.Add(newProduct);
            context.SaveChanges();
            // 挿入直後にIDがセットされている
            Console.WriteLine($"Inserted Product ID: {newProduct.Id}");
        }
    }
}

Inserted Product ID: 1

この例では、SaveChangesの呼び出し後にnewProduct.Idに自動生成されたIDが格納されていることが確認できます。

EFはINSERT文の実行後にSCOPE_IDENTITY()やRETURNING句などを利用してIDを取得し、エンティティに反映しています。

Selectでプロジェクション

挿入後に特定のカラムだけを取得したい場合や、複数のエンティティから必要な情報だけを抽出したい場合は、LINQのSelectメソッドを使ってプロジェクション(投影)を行います。

これにより、不要なデータの取得を避け、パフォーマンスを向上させることができます。

例えば、ProductテーブルからNameとPriceだけを取得して表示する例です。

using System;
using System.Linq;
using Microsoft.EntityFrameworkCore;
class Program
{
    static void Main()
    {
        using (var context = new ApplicationDbContext())
        {
            // 事前にデータを挿入
            context.Products.Add(new Product { Name = "Product A", Price = 10m });
            context.Products.Add(new Product { Name = "Product B", Price = 20m });
            context.SaveChanges();
            // NameとPriceだけを取得するプロジェクション
            var productInfos = context.Products
                .Select(p => new { p.Name, p.Price })
                .ToList();
            foreach (var info in productInfos)
            {
                Console.WriteLine($"Name: {info.Name}, Price: {info.Price}");
            }
        }
    }
}

Name: Product A, Price: 10
Name: Product B, Price: 20

このコードでは、Selectで匿名型を使い、NameとPriceだけを抽出しています。

SQLクエリも必要なカラムだけを取得する形に最適化されるため、データ転送量が減り効率的です。

また、プロジェクションはDTO(Data Transfer Object)やViewModelにマッピングする際にも活用され、UIやAPIのレスポンスに必要なデータだけを返す設計に役立ちます。

挿入直後のID取得とLINQのSelectによるプロジェクションを組み合わせることで、効率的かつ柔軟なデータ操作が可能になります。

これにより、データベースとのやり取りを最小限に抑えつつ、必要な情報を適切に取得できるようになります。

よくある落とし穴

Lazy Loadingによる意図しない挿入

Entity FrameworkのLazy Loading機能は、ナビゲーションプロパティにアクセスした際に関連エンティティを自動的にデータベースから読み込む便利な機能です。

しかし、この機能が原因で意図しない挿入や更新が発生することがあります。

Lazy Loadingが有効な場合、親エンティティのナビゲーションプロパティにアクセスすると、EFが自動的に関連エンティティをロードします。

もしその関連エンティティが新規作成されたオブジェクトであったり、状態がAddedに設定されている場合、SaveChanges時にそれらも一緒に挿入されてしまいます。

例えば、以下のようなケースです。

public class Order
{
    public int Id { get; set; }
    public virtual Customer Customer { get; set; }  // Lazy Loading対象
}
public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

using (var context = new ApplicationDbContext())
{
    var order = new Order();
    order.Customer = new Customer { Name = "New Customer" };  // 新規Customerをセット
    context.Orders.Add(order);
    context.SaveChanges();  // OrderとCustomerの両方が挿入される
}

この場合、Orderを追加すると同時にCustomerも新規挿入されます。

Lazy Loadingが原因で関連エンティティの状態が追跡され、意図しない挿入が発生することがあります。

対策としては以下が挙げられます。

Lazy Loadingを無効化する

DbContextの設定でLazy Loadingをオフにし、明示的にIncludeやLoadを使って関連データを取得します。

関連エンティティの状態を明示的に管理する

新規挿入したくない関連エンティティはDetachedに設定するか、既存のエンティティとしてAttachします。

ナビゲーションプロパティに新規オブジェクトをセットしない

既存のエンティティを参照する場合は、IDだけをセットしてAttachします。

Lazy Loadingは便利ですが、挿入や更新の挙動を把握しないと予期せぬデータベース操作を引き起こすため、注意が必要です。

循環参照問題とCascade Insert

親子関係のエンティティで相互にナビゲーションプロパティを持つ場合、循環参照が発生しやすくなります。

これにより、Entity FrameworkのCascade Insert(カスケード挿入)機能が意図しない複数回の挿入や無限ループを引き起こすことがあります。

例えば、ParentとChildが互いにナビゲーションプロパティを持つ場合です。

public class Parent
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<Child> Children { get; set; } = new List<Child>();
}
public class Child
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Parent Parent { get; set; }
}

この状態で、親と子の両方に新規オブジェクトを作成し、相互に参照を設定してからAddすると、EFは両方のエンティティを挿入対象として認識し、Cascade Insertを行います。

var parent = new Parent { Name = "Parent1" };
var child = new Child { Name = "Child1", Parent = parent };
parent.Children.Add(child);
context.Parents.Add(parent);
context.SaveChanges();

この場合は正常に動作しますが、循環参照が複雑になると、EFが状態管理に混乱し、重複挿入や例外が発生することがあります。

対策としては以下の方法があります。

ナビゲーションプロパティの設定を最小限にする

片方向のナビゲーションだけを設定し、循環を避けます。

[JsonIgnore]や[IgnoreDataMember]属性でシリアル化時の循環を防ぐ

APIレスポンスなどで循環参照が問題になる場合に有効。

Cascade DeleteやCascade Insertの設定を明示的に制御する

Fluent APIでOnDeleteの動作を制御し、不要なカスケードを防止します。

エンティティの状態を明示的に管理する

既存エンティティはAttachし、新規エンティティのみAddすることで重複挿入を防ぐ。

循環参照は特に複雑なドメインモデルで発生しやすいため、設計段階でナビゲーションプロパティの関係性を整理し、EFの挙動を理解した上で適切に管理することが重要です。

セキュリティ上の注意

SQLインジェクションを防ぐ

SQLインジェクションは、悪意のあるユーザーが入力フィールドなどを通じて不正なSQL文を注入し、データベースの情報漏洩や改ざんを引き起こす攻撃手法です。

Entity Framework(EF)を利用する際も、SQLインジェクションのリスクを理解し、適切な対策を講じることが重要です。

EFはLINQやパラメータ化クエリを標準でサポートしているため、通常のクエリ操作ではSQLインジェクションのリスクは低減されています。

例えば、以下のようにLINQで条件を指定する場合、EFは自動的にパラメータ化して安全なSQLを生成します。

string userInput = "example'; DROP TABLE Products; --";
var products = context.Products
    .Where(p => p.Name == userInput)
    .ToList();

このコードは、userInputに悪意のあるSQL文が含まれていても、EFがパラメータ化して処理するため、SQLインジェクションは防止されます。

しかし、以下のような生のSQLを直接文字列連結で実行する場合は注意が必要です。

string userInput = "example'; DROP TABLE Products; --";
var products = context.Products
    .FromSqlRaw($"SELECT * FROM Products WHERE Name = '{userInput}'")
    .ToList();

このように文字列補間や連結でSQL文を組み立てると、SQLインジェクションのリスクが高まります。

対策としては、必ずパラメータを使うことです。

var products = context.Products
    .FromSqlRaw("SELECT * FROM Products WHERE Name = {0}", userInput)
    .ToList();

または、FromSqlInterpolatedを使う方法もあります。

var products = context.Products
    .FromSqlInterpolated($"SELECT * FROM Products WHERE Name = {userInput}")
    .ToList();

これらはパラメータ化され、安全にSQLが実行されます。

まとめると、SQLインジェクションを防ぐポイントは以下の通りです。

LINQクエリを使い、生のSQL文字列を直接組み立てない
生のSQLを使う場合は必ずパラメータ化を行います
ユーザー入力は検証・サニタイズを行います
ORMの機能を活用し、安全なクエリ生成を心がける

楽観的同時実行制御

複数のユーザーやプロセスが同時に同じデータを更新する場合、データの競合や上書きが発生するリスクがあります。

これを防ぐために、Entity Frameworkでは楽観的同時実行制御(Optimistic Concurrency Control)が利用できます。

楽観的同時実行制御は、データの更新時に「他のユーザーが同じデータを変更していないか」をチェックし、競合があれば例外を発生させて処理を中断します。

これにより、意図しない上書きを防止できます。

EFで楽観的同時実行制御を実装するには、エンティティに「バージョン管理用のプロパティ」を追加し、[Timestamp]属性やIsRowVersion設定を使います。

例えば、以下のようにRowVersionプロパティを定義します。

using System.ComponentModel.DataAnnotations;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    [Timestamp]
    public byte[] RowVersion { get; set; }
}

このRowVersionはデータベースのrowversion型(SQL Serverの場合)と連携し、更新のたびに自動的に値が変わります。

更新処理時に、EFはRowVersionの値をWHERE句に含めて更新を試み、他のユーザーが更新していれば影響行数が0となり、DbUpdateConcurrencyExceptionがスローされます。

例外処理の例は以下の通りです。

try
{
    context.SaveChanges();
}
catch (DbUpdateConcurrencyException ex)
{
    Console.WriteLine("データの競合が発生しました。再読み込みして再試行してください。");
    // 競合解決のためのロジックをここに記述
}