Як очистити відстежувані сутності в рамках сутності

Question 1

Я запускаю деякий код виправлення, який запускається через велику купу сутностей, оскільки його прогрес зменшується, це означає, що кількість відстежуваних сутностей у контексті збільшується з кожною ітерацією. Це може зайняти багато часу, тому я зберігаю зміни в кінці кожної ітерації. Кожна ітерація є незалежною і не змінює попередньо завантажені сутності.

Я знаю, що можу відключити відстеження змін, але не хочу, оскільки це не код масової вставки, а завантаження сутностей та обчислення кількох речей, а якщо цифри неправильні, встановіть нові номери та оновіть / видаліть / створіть деякі додаткові сутності. Я знаю, що можу створити новий DbContext для кожної ітерації, і, ймовірно, це буде працювати швидше, ніж робити все в тому ж екземплярі, але я думаю, що може бути кращий спосіб.

Тож питання в тому; Чи є спосіб очищення сутностей, раніше завантажених у контексті db?

Question 2

Ви можете додати метод до свого DbContextабо методу розширення, який використовує ChangeTracker для від'єднання всіх доданих, модифікованих та видалених сутностей:

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;
}

Question 3

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

Question 4

Я запускаю службу Windows, яка щохвилини оновлює значення, і у мене була та сама проблема. Я спробував запустити рішення @DavidSherrets, але через кілька годин це теж повільно. Моє рішення полягало в тому, щоб просто створити такий контекст, як цей, для кожного нового запуску. Просто, але це працює.

_dbContext = new DbContext();

Question 5

Я просто зіткнувся з цією проблемою і врешті-решт натрапив на краще рішення для тих, хто використовує типову ін’єкцію залежностей .NET Core. Для кожної операції ви можете використовувати DbContext з масштабом. Це буде скинуто, DbContext.ChangeTrackerщоб SaveChangesAsync()не заглиблюватися в перевірку сутностей із минулих ітерацій. Ось приклад методу контролера ASP.NET Core:

    /// <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

Question 6

У EF Core 3.0 є внутрішній API, який може скинути ChangeTracker. Не використовуйте це у виробничому коді, я згадую це, оскільки це може допомогти комусь у тестуванні залежно від сценарію.

using Microsoft.EntityFrameworkCore.Internal;

_context.GetDependencies().StateManager.ResetState();

Як сказано в коментарі до кодексу;

Це внутрішній API, який підтримує базову інфраструктуру Entity Framework і не підпадає під ті ж стандарти сумісності, що і загальнодоступні API. Він може бути змінений або видалений без попередження у будь-якому випуску. Ви повинні використовувати його безпосередньо у своєму коді лише з особливою обережністю, знаючи, що це може призвести до збоїв програми під час оновлення до нового випуску Entity Framework Core.

Question 7

EntityFramework Core 5.0 представив новий метод очищення будь-яких відстежуваних змін.

_context.ChangeTracker.Clear();

https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.changetracking.changetracker.clear?view=efcore-5.0

Question 8

Ну, моя думка така, що, на моєму досвіді, EF або будь-який орган не працює добре під великим тиском або складною моделлю.

Якщо ви не хочете відстежувати, справді я б сказав, навіщо взагалі робити орм?

Якщо швидкість є головною силою, ніщо не може перевершити збережені процедури та хорошу індексацію.

І далі, якщо ваші запити завжди відповідають ідентифікатору, розгляньте можливість використання nosql або, можливо, sql з лише key і json. Це дозволить уникнути проблеми імпедансу між класами та таблицями.

Для вашого випадку завантаження речей у об’єкти таким чином мені здається дуже повільним. Насправді у вашому випадку збережені процедури є кращими, тому що ви уникаєте транспортування даних через мережу, а sql набагато швидший та оптимізованіший для управління агрегацією та подібними речами.