エンティティの大きな山を実行する修正コードを実行しています。速度が低下するにつれて、コンテキスト内の追跡されるエンティティの数が反復ごとに増加するためです。時間がかかる可能性があるため、最後に変更を保存しています。各反復の。各反復は独立しており、以前にロードされたエンティティを変更しません。
変更の追跡をオフにできることはわかっていますが、一括挿入コードではないため、オフにしたくありませんが、エンティティを読み込んでいくつかの計算を行い、数値が正しくない場合は、新しい数値を設定して更新/削除/作成しますいくつかの追加エンティティ。反復ごとに新しいDbContextを作成でき、おそらく同じインスタンスですべてを実行するよりも高速に実行できることはわかっていますが、もっと良い方法があるのではないかと考えています。
したがって、問題は次のとおりです。以前にdbコンテキストにロードされたエンティティをクリアする方法はありますか？
回答:
DbContextChangeTrackerを使用して、追加、変更、および削除されたすべてのエンティティをデタッチするメソッドを、または拡張メソッドに追加できます。
public void DetachAllEntities()
{
var changedEntriesCopy = this.ChangeTracker.Entries()
.Where(e => e.State == EntityState.Added ||
e.State == EntityState.Modified ||
e.State == EntityState.Deleted)
.ToList();
foreach (var entry in changedEntriesCopy)
entry.State = EntityState.Detached;
}
var entity必要がありますvar entry）
1.可能性：エントリを切り離します
dbContext.Entry(entity).State = EntityState.Detached;
エントリをデタッチすると、変更トラッカーはエントリの追跡を停止します（パフォーマンスが向上するはずです）
参照：http：//msdn.microsoft.com/de-de/library/system.data.entitystate（v = vs.110）.aspx
2.可能性：独自のStatusフィールド+切断されたコンテキストで作業する
切断されたグラフを使用できるように、エンティティのステータスを個別に制御したい場合があります。エンティティステータスのプロパティを追加し、このステータスdbContext.Entry(entity).Stateを操作の実行時に変換します（これを行うにはリポジトリを使用します）
public class Foo
{
public EntityStatus EntityStatus { get; set; }
}
public enum EntityStatus
{
Unmodified,
Modified,
Added
}
例については、次のリンクを参照してください：https：//www.safaribooksonline.com/library/view/programming-entity-framework/9781449331825/ch04s06.html
毎分値を更新するWindowsサービスを実行していますが、同じ問題が発生しました。@DavidSherretsソリューションを実行してみましたが、数時間後にはこれも遅くなりました。私の解決策は、新しい実行ごとにこのような新しいコンテキストを作成することでした。シンプルですが、機能します。
_dbContext = new DbContext();
私はちょうどこの問題に遭遇し、最終的には典型的な.NETCore依存性注入を使用している人のためのより良い解決策に出くわしました。操作ごとにスコープ付きDbContextを使用できます。これはリセットされるDbContext.ChangeTrackerため、SaveChangesAsync()過去の反復からエンティティをチェックするのに行き詰まることはありません。ASP.NET CoreControllerメソッドの例を次に示します。
/// <summary>
/// An endpoint that processes a batch of records.
/// </summary>
/// <param name="provider">The service provider to create scoped DbContexts.
/// This is injected by DI per the FromServices attribute.</param>
/// <param name="records">The batch of records.</param>
public async Task<IActionResult> PostRecords(
[FromServices] IServiceProvider provider,
Record[] records)
{
// The service scope factory is used to create a scope per iteration
var serviceScopeFactory =
provider.GetRequiredService<IServiceScopeFactory>();
foreach (var record in records)
{
// At the end of the using block, scope.Dispose() will be called,
// release the DbContext so it can be disposed/reset
using (var scope = serviceScopeFactory.CreateScope())
{
var context = scope.ServiceProvider.GetService<MainDbContext>();
// Query and modify database records as needed
await context.SaveChangesAsync();
}
}
return Ok();
}
ASP.NET Coreプロジェクトは通常DbContextPoolを使用するため、これによってDbContextオブジェクトが作成/破棄されることはありません。（あなたが興味を持っていた場合は、DbContextPoolが実際に呼び出すDbContext.ResetState()とDbContext.Resurrect()が、彼らはおそらく、将来のリリースで変更されますように私は、あなたのコードから直接それらを呼び出すことをお勧めしません。）
https://github.com/aspnet/EntityFrameworkCore/blob/v2 .2.1 / src / EFCore / Internal / DbContextPool.cs＃L157
EF Core 3.0から、ChangeTrackerをリセットできる内部APIがあります。これを本番コードで使用しないでください。シナリオによってはテストに役立つ可能性があるため、言及します。
using Microsoft.EntityFrameworkCore.Internal;
_context.GetDependencies().StateManager.ResetState();
コードのコメントが言うように;
これは、Entity Framework Coreインフラストラクチャをサポートする内部APIであり、パブリックAPIと同じ互換性標準の対象ではありません。いかなるリリースにおいても、予告なしに変更または削除される場合があります。細心の注意を払ってコード内で直接使用する必要があります。そうすると、新しいEntity FrameworkCoreリリースに更新するときにアプリケーションが失敗する可能性があることを認識してください。
EntityFramework Core 5.0では、追跡された変更をクリアするための新しいメソッドが導入されました。
_context.ChangeTracker.Clear();
私の意見では、私の経験では、EF、または任意のオームであることは、過度のプレッシャーや複雑なモデルではうまく機能しないということです。
追跡したくない場合は、本当にormを実行するのはなぜですか？
速度が主な力である場合、ストアドプロシージャと優れたインデックス作成に勝るものはありません。
さらに、クエリが常にIDごとである場合は、nosqlまたはおそらくkeyとjsonだけのsqlを使用することを検討してください。これにより、クラスとテーブル間のインピーダンスの問題を回避できます。
あなたのケースシナリオでは、そのようにオブジェクトに物をロードするのは私には非常に遅いようです。実際の場合、ネットワークを介したデータの転送を回避できるため、ストアドプロシージャの方が優れています。また、SQLははるかに高速で、集計などを管理するために最適化されています。
context.Entry(entity).State = EntityState.Detached、その特定のエンティティの追跡が停止します。