mcpField
E
entity-framework6

entity-framework6

github.com/managedcodeデータ・データベース49639 回インストール今日更新
リポジトリ

entity-framework6 について

EF6 アプリケーションを保守するチームや、EF Core への移行を検討するチーム向けのガイダンスです。実際に使われている EF6 の機能を洗い出し、ランタイムの更新と ORM の移行を分けて計画します。

主な機能

  1. 01EF6 固有パターンの監査
  2. 02ランタイムと ORM の更新を区別
  3. 03境界づけられたコンテキストの移行計画
  4. 04実データベースでの検証
  5. 05EF6 の保守手法の適用

活用シーン

  1. 01EDMX ベースのレガシーデータ層の評価
  2. 02EF6 を維持したランタイム更新
  3. 03EF Core 移行の計画
  4. 04移行後のクエリと動作のテスト

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/managedcode/dotnet-skills --skill entity-framework6

インストール後、Claude Code で/entity-framework6を入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

manifest.json
references/
migration.md
patterns.md

詳細

Entity Framework 6

発動条件

  • .NET Framework または最新の .NET で EF6 のコードベースを扱う場合
  • EF6 を維持するか、最新の .NET ランタイムに移行するか、EF Core に移植するかを判断する場合
  • EDMX、コードファースト、またはレガシーな ASP.NET/WPF/WinForms のデータアクセスをレビューする場合
  • データレイヤーの移行戦略を計画する場合

ワークフロー

  1. 移行を計画する前に、現在の EF6 の使用状況を監査します。コードベースが依存している機能を特定します。

    // Common EF6-specific patterns to inventory:
    // - EDMX designer models (check for *.edmx files)
    // - ObjectContext vs DbContext usage
    // - Lazy loading with virtual navigation properties
    // - Database.SqlQuery<T>() for raw SQL
    // - Stored procedure mappings in model
    // - Spatial types (DbGeography, DbGeometry)
    
  2. ランタイムの移行と ORM の移行を別々に判断します。

    パス使用する状況
    .NET Framework 上で EF6 を維持するランタイムの変更が急務ではないレガシーアプリ
    最新の .NET 上で EF6 を使うランタイムのアップグレードが必要だが、ORM の移行はリスクが高すぎる
    EF6 → EF Coreデータレイヤーが整理されており、EDMX がなく、ストアドプロシージャのマッピングが最小限
  3. 保守作業では、EF6 の安定性を維持します。

    • リポジトリおよびユニットオブワークのパターンを使用して、データアクセスを分離します(references/patterns.md を参照)
    • 新しいコードでは ObjectContext より DbContext を優先します
    • 読み取り専用クエリには AsNoTracking() を使用します
    • [ConcurrencyCheck] または IsRowVersion() で同時実行トークンを設定します
  4. 移行作業では、各スライスを検証します。

    • EF6 の機能を EF Core の同等機能に対応付けます(references/migration.md を参照)
    • データレイヤー全体ではなく、境界を明確にしたコンテキストを一度に 1 つずつ移行します
    • InMemory ではなく、実際のデータベースプロバイダーに対して統合テストを実行します
    • dotnet ef migrations add が成功すること、クエリが同等の結果を返すこと、遅延読み込みの動作が期待どおりであることを確認します
  5. EF6 のコードベースに EF Core の機能を約束しないでください。 EF6 は安定しておりサポートされていますが、積極的な開発の対象ではありません。期待値を現実的に保ちます。

最新のアップストリーム情報

  • 2026 年 8 月の EF Core と EF6 の比較では、ORM の移行判断とランタイムのモダナイズを分けています。EF6 は引き続きサポートされていますが、積極的には開発されていません。EDMX、ObjectContext、または複雑なレガシーマッピングがリスクの大部分を占める場合は、引き続き適切な ORM となる可能性があります。
  • EF Core v10.0.11 のサービスリリースがあっても、EF Core がそのまま置き換え可能になるわけではなく、それだけで EF6 の指針が変わることもありません。明確に範囲を限定した移行スライスがあり、データベースを使った同等性テストを実施できる場合にのみ移行してください。
flowchart LR
  A["Audit EF6 usage"] --> B{"EDMX or complex mappings?"}
  B -->|Yes| C["High migration cost — consider keeping EF6"]
  B -->|No| D["Evaluate EF Core migration"]
  D --> E["Migrate one context at a time"]
  E --> F["Integration test against real DB"]
  C --> G["Modernize runtime only"]
  F --> H["Validate query equivalence"]
  G --> H

提供内容

  • 実際のコードベース監査に基づく、現実的な EF6 の保守または移行のガイダンス
  • ランタイムのアップグレード作業と ORM のアップグレード作業の明確な分離
  • 具体的な検証チェックポイントを設けた、範囲を限定した移行スライス
  • レガシーなデータアクセスの変更に伴うリスクの低減

検証

  • 移行計画を開始する前に、EF6 の機能一覧を完全に作成している
  • 移行に関する前提が推測ではなく、実際の機能使用状況に基づいている
  • EF6 専用の機能(EDMX、空間型、ObjectContext のパターン)を早期に特定している
  • モックや InMemory ではなく、実際のデータベースプロバイダーに対して統合テストを実行している
  • 提案するパスが、安定したデータアクセスコードへの不要な変更を避けている

参考資料

  • references/migration.md - 判断フレームワーク、移行アプローチ、EF6 から EF Core への機能対応、およびよくある落とし穴
  • references/patterns.md - EF6 のコードベース向けのリポジトリおよびユニットオブワークのパターン、クエリの最適化、同時実行の処理、監査、テスト戦略

コメント