EntityFrameworkCoreを使用するためのヒント

こんにちは。



私は最近、EFを使用するすべての人がEFの調理方法を知っているわけではないことを発見しました。さらに、彼らは理解することに熱心ではありません。非常に早い段階で問題に直面している-セットアップ。

構成が成功した後でも、データ要求に問題があります。人々がLINQを知らないからではなく、すべてがオブジェクトからリレーショナルモデルにマッピングできるわけではないからです。リンクを操作するとき、人々はテーブルで考えるからです。SQLクエリを描画し、それらをLINQに変換してみます。



これと、おそらく、私が記事で話したい他の何か。

セットアップ

ある人がプロジェクトに来て、そこで初めてEFを見て、そのような奇跡に驚いて、それを使うことを学び、個人的な目的に使うことに決めました。新しいプロジェクトを作成しました...そして何をしますか？



あなたはグーグル、試行、エラーを開始します。 EFをプロジェクトに単純に接続するために、開発者は理解できない種類の問題に直面します。



1.必要なDBMSで動作するように構成するにはどうすればよいですか？

2.移行の作業を構成するにはどうすればよいですか？



もっと問題があると思いますが、おそらくこれらが最も頻繁な問題です。すべてを順番に話しましょう。



1.さて、これはグーグルです。 :)あなたの仕事は、DBMS用のEntityFrameworkコアプロバイダーを見つけることです。



また、プロバイダーの説明には、セットアップの手順が記載されています。



たとえば、PostgreSQLの場合、NugetパッケージNpgsql.EntityFrameworkCore.PostgreSQLをインストールする必要があります。

DbContextOptionsを受け入れる独自のコンテキストを作成し、次のように全体を作成します

var opts = new DbContextOptionsBuilder<MyDbContext>()
        .UseNpgsql(constring);

var ctx = new MyDbContext(opts.Options);

ASP .NET Coreアプリケーションを使用している場合、コンテキストはコンテナーに異なる方法で登録されます。しかし、あなたはすでにあなたの作業プロジェクトでこれを見ることができます。またはグーグル。



2.会社に乳母がいない場合は、移行を操作するために必要なツールをインストールする方法を知っている可能性があります。パッケージマネージャー用かNETCoreCLI用か。



ただし、気付いていないかもしれませんが、選択したスタートアッププロジェクト（--startup-project）は、移行を操作するときに開始されます。つまり、移行の開始プロジェクトがアプリケーションを起動するプロジェクトと同じであり、何らかの理由で開始したときにctx.Database.Migrate（）を使用して移行をロールし、作成しようとすると、以前に作成した移行を削除するか、別の移行を作成します。最後に作成された移行がベースにロールされます。驚き！



しかし、おそらく、最初の移行を作成しようとすると、次のようなものが見つかります

このDbContextにはデータベースプロバイダーが構成されていません。プロバイダーは、DbContext.OnConfigureメソッドをオーバーライドするか、アプリケーションサービスプロバイダーでAddDbContextを使用して構成できます。AddDbContextを使用する場合は、DbContextタイプがコンストラクターでDbContextOptions <TContext>オブジェクトを受け入れ、それをDbContextの基本コンストラクターに渡すことも確認してください。

これは、移行を処理するツールがコンテキストに基づいて移行を作成するためですが、このためにはインスタンスが必要です。それを提供するには、スタータープロジェクトにIDesignTimeDbContextFactoryインターフェイスを実装する必要があります。これは難しくありません。コンテキストのインスタンスを返す必要があるメソッドは1つだけです。

モデルの設定

最初の移行はすでに作成されていますが、何らかの理由で空です。モデルはありますが。



重要なのは、モデルをデータベースに変換するためのコンテキストを教えていないということです。



EFが移行を作成してデータベースにモデルのテーブルを作成するには、少なくともコンテキストにDbSet <MyEntity>タイプのプロパティを作成する必要があります。



たとえば、このプロパティによって

public DbSet <MyEntity> MyEntities {get;セットする; }



MyEntitiesテーブルはMyEntityエンティティのプロパティに対応するフィールドを使用して作成されます。



DbSetを使用したくない場合、またはエンティティのデフォルトのテーブル作成ルールに影響を与えたい場合は

protected override void OnModelCreating(ModelBuilder modelBuilder)

、コンテキストのメソッドをオーバーライドする必要があります。



これを行う方法、あなたはおそらく知っています。さらに、マッピングルールを制御できる属性についてはおそらくご存知でしょう。しかし、ここにあります。属性ではマッピングを完全に制御できません。つまり、OnModelCreatingを改良する必要があります。つまり、注釈の形式と流暢なapiの形式の両方でエンティティをマッピングするためのルールがあります。次に、フィールドの名前が間違っている理由、予想どおりの名前、または間違った制限を探します。



-それでは、すべてが単純です-あなたが言う-OnModelCreatingを介してすべてを構成します



そして、10個のフィールドから20番目のエンティティを設定した後、あなたの目は波打つようになります。あるエンティティのフィールド設定を見つけようとしていますが、200〜500行の長さの均一なブロックからすべてが目の前に浮かんでいます。



はい、このブロックを20のメソッドに分割でき、少し簡単になります。ただし、IEntityTypeConfiguration <TEntity>インターフェイスがあることを知っておくと便利です。これを実装することで、特定のエンティティに対して、この実装で特定のエンティティのマッピングルールを記述できます。コンテキストがそれを取得するには、

OnModelCreatingでmodelBuilder.ApplyConfigurationsFromAssembly（assemblyWithConfigurations）;を記述する必要があります。



そしてもちろん、一般的な動作を同じOnModelCreatingに転送することもできます。たとえば、すべてまたは多数のエンティティの識別子に関する一般的なルールがある場合は、次のように構成できます。

foreach (var idEntity in modelBuilder.Model.GetEntityTypes()
    .Where(x => typeof(BaseIdEntity).IsAssignableFrom(x.ClrType))
    .Select(x => modelBuilder.Entity(x.ClrType)))
{
    idEntity.HasKey(nameof(BaseIdEntity.Id));
}

クエリの作成

さて、整理整頓して、もう少し気持ちよくなりました。



現在、ホームプロジェクトのクエリをSQLからLinqにやり直す必要があります。私はすでに仕事でリクエストを書いています、それは

梨を砲撃するのと同じくらい簡単ですctx.MyEntities.Where（条件）.Select（マップ）.GroupBy（式）.OrderBy（式）…軽さ。



それで、私たちの要求は何ですか？

SELECT bla bla bla FROM table
RIGHT JOIN....... 

ええ

ctx.LeftEntities.RightJoin(.... f@#$

私はEFを知るずっと前から、Linqとその拡張メソッドを使用してきました。一度も質問はありませんでしたが、RIGHT JOIN、LEFT JOINは



どこにありますか...オブジェクトの観点からLEFTJOINとは何ですか？



それ

class LeftEntity 
{
    public List<RightEntity> RightEntities { get; set; }
}

それも魔法ではありません。他のエンティティのリストを参照する特定のエンティティがありますが、ない場合があります。



つまり、これ

ctx.LeftEntities.Include(x => x.RightEntities)

RIGHT JOINとは何ですか？これは逆LEFTJOINです。つまり、別のエンティティから始めます。



ただし、すべてが発生します。左側のエンティティが単一の右側のエンティティに関連付けられていない場合（右側のエンティティがNULLの場合）でも、各バンドルを個別のエンティティとして制御する必要がある場合があります。したがって、明示的にLEFTJOINは次のように実行できます。

ctx.LeftEntities.SelectMany(x => x.RightEntities.DefaultIfEmpty(), (l, r) => new { Left = l, Right = r })

これにより、リレーショナルモデルの場合と同様に、バインディングを制御できます。なぜあなたはそれを必要とするのでしょうか？顧客がデータをテーブルの形式で表示する必要があり、並べ替えやページ付けが必要であるとします。



私もこのアイデアは好きではありませんが、Excelには誰もが独自の癖と無限の愛を持っています。それで、マットを咳で覆い、こぶしに呪いをかけ、仕事を続けます。次は何ですか？

FULL JOIN

だから、まあ、私はすでに理解しました、私たちはSQLで考えていません、私たちはこのようなオブジェクトで考えています、そして今このように...くそー。これをどのように表現しますか？



タプルなしでは、どこにも。



一般に、タプルを使用する必要がある場合、接続のタイプ（1-1、1-n、nn）についての理解が失われ、一般に、理論的には、ハエと象を交差させることができます。これは黒い魔法です。

やってみましょう！



基礎として多対多を取りましょう。



したがって、3種類のエンティティ



LeftEntity

RightEntity

LeftRight（接続を整理するため）



LeftRightを合成キーで作成します。このエンティティに直接アクセスする必要はありません。外部から参照する必要がないため、不要なフィールドやインデックスを作成しません。



クエリの結果として、左側のエンティティと右側のエンティティを含むタプルのセットを取得したいと思います。さらに、バージンエンティティが正しいエンティティとは何の関係もない場合、正しいオブジェクトはnullになります。同じことが右側のエンティティにも当てはまります。



LeftRightは出力としては適していないことが判明しました。その制限により、エンティティの1つがないとバンドルを作成できません。 DDDを練習すると、矛盾が発生します。

練習しなくても、練習すべきではありません。

LeftRightFull出力の新しいタイプを作成しましょう。これには、左右のエンティティへのリンクが含まれています。



だから、我々は



左

L1

L2



右

R1

R2



LeftRight

L2 R2を



私たちは、出力で欲しい

L1 N

L2 R2

nR1



左側の接続から始めましょう

var query = ctx.LeftEntities
    .SelectMany(x => x.RightLinks.DefaultIfEmpty(), (l, lr) => new LeftRightFull
    {
        LeftEntity = l,
        RightEntity = lr.RightEntity
    })

今、私たちはすでに

L1 n

L2 R2を持っています



次は何ですか？ SelectManyを介してRightEntityをスティックしますか？さて、

L1 n R1 n

L1 n R2 L2

L2 R2 R1 n

L2 R2 R2 L2を取得



します。条件によって不要なもの（L2 R2 R1nおよびL1n R2 L2）を除外できますが、L1 n R1nを変換する方法は不明です。 in

L1 n

n R1



おそらく、発掘によって私たちは間違った階段に連れて行かれました。これらの同様のクエリを、Unionを介して左右のエンティティの左結合に接続してみましょう。

L1 n

L2 R2

UNION

L2 R2

nR1



ここでパフォーマンスについて質問があるかもしれません。すべてが特定のDBMSとそのオプティマイザの細心さに依存するため、私はそれらに答えません。



または、目的のクエリを使用してビューを作成することもできます。UnionはEFCore 2で動作しないため、ビューを作成する必要がありました。ただし、忘れないことをお勧めします。突然、IsDeletedフラグを使用してエンティティのソフト削除を実装することにしました。ビューでは、これをサポートする必要があります。忘れてしまった場合、いつバグレポートを受け取るかはわかりません。



ちなみに、コード全体を書き直さずにソフト削除を実装するにはどうすればよいですか？次回はこれについてお話します。多分何か他のもの。



みなさん、さようなら。