Parallelism and Entity Framework

Question

Очень часто в наших веб-приложениях нужны данные из разных таблиц в нашей базе данных. Сегодня вы можете найти 5 или 6 запросов к базе данных, которые выполняются последовательно для одного запроса. Ни один из этих запросов не зависит от данных от другого, поэтому они являются идеальными кандидатами для параллельного выполнения. Проблема заключается в хорошо известном DbConcurrencyException, который генерируется, когда несколько запросов выполняются в одном контексте.

Обычно мы используем один контекст для каждого запроса, а затем имеем класс репозитория, чтобы мы могли повторно использовать запросы по различным проектам. Затем мы удаляем контекст в конце запроса, когда контроллер находится.

Ниже приведен пример, в котором используется параллелизм, но все еще есть проблема!

var fileTask = new Repository().GetFile(id); 
var filesTask = new Repository().GetAllFiles(); 
var productsTask = AllProducts(); 
var versionsTask = new Repository().GetVersions(); 
var termsTask = new Repository().GetTerms(); 

await Task.WhenAll(fileTask, filesTask, productsTask, versionsTask, termsTask); 

Каждый репозиторий внутренне создает свой собственный контекст, но, как и сейчас, они не располагаются. Это проблема. Я знаю, что могу позвонить Dispose в каждый репозиторий, который я создаю, но это начинает быстро загромождать код. Я мог бы создать функцию-оболочку для каждого запроса, который использует свой собственный контекст, но это кажется беспорядочным и не является большим долгосрочным решением проблемы.

Что было бы лучшим способом решить эту проблему? Я бы хотел, чтобы клиент/потребитель не беспокоился об утилизации каждого репозитория/контекста в случае одновременного выполнения нескольких запросов.

Единственная идея, которую я имею сейчас, - это следовать подходу, подобному заводской схеме, за исключением того, что мой завод будет отслеживать все созданные им объекты. Тогда я мог бы продать завод, как только я узнаю, что мои запросы завершены, и фабрика может внутренне распоряжаться каждым репозиторием/контекстом.

Я удивлен увидеть такую ​​маленькую дискуссию вокруг параллельности и Entity Framework, так что мы надеемся, еще некоторые идеи из сообщества придут.

Редактировать

Вот простой пример того, что наш репозиторий выглядит так:

public class Repository : IDisposable { 
    public Repository() { 
     this.context = new Context(); 
     this.context.Configuration.LazyLoadingEnabled = false; 
    } 

    public async Task<File> GetFile(int id) { 
     return await this.context.Files.FirstOrDefaultAsync(f => f.Id == id); 
    } 

    private bool disposed = false; 

    protected virtual void Dispose(bool disposing) { 
     if (!this.disposed) { 
      if (disposing) { 
       context.Dispose(); 
      } 
     } 
     this.disposed = true; 
    } 

    public void Dispose() { 
     Dispose(true); 
     GC.SuppressFinalize(this); 
    } 
} 

Как вы можете видеть, каждый репозиторий получает свой собственный контекст. Это означает, что каждый репозиторий необходимо утилизировать. В приведенном выше примере, это означает, что мне понадобится 4 обращения к Dispose().

Мои мысли для фабричного подхода к проблеме было что-то вроде следующего:

public class RepositoryFactory : IDisposable { 
    private List<IRepository> repositories; 

    public RepositoryFactory() { 
     this.repositories = new List<IRepository>(); 
    } 

    public IRepository CreateRepository() { 
     var repo = new Repository(); 
     this.repositories.Add(repo); 
     return repo;    
    } 

    #region Dispose 
    private bool disposed = false; 

    protected virtual void Dispose(bool disposing) { 
     if (!this.disposed) { 
      if (disposing) { 
       foreach (var repo in repositories) { 
        repo.Dispose(); 
       } 
      } 
     } 
     this.disposed = true; 
    } 

    public void Dispose() { 
     Dispose(true); 
     GC.SuppressFinalize(this); 
    } 
    #endregion 
} 

Этот завод будет отвечать за создание экземпляров моего репозитория, но он также будет следить за всеми экземплярами она имеет создано. Как только этот единственный заводский класс будет удален, он будет внутренне отвечать за удаление каждого созданного им репозитория.

Answer 1

Вы можете разрешить клиентам конфигурировать поведение удаления Repository, передав конструктору необязательный (по умолчанию по умолчанию) autodispose бит. Реализация будет выглядеть примерно так:

public class Repository : IDisposable 
{ 
    private readonly bool _autodispose = false; 
    private readonly Lazy<Context> _context = new Lazy<Context>(CreateContext); 

    public Repository(bool autodispose = false) { 
     _autodispose = autodispose; 
    } 

    public Task<File> GetFile(int id) { 
     // public query methods are still one-liners 
     return WithContext(c => c.Files.FirstOrDefaultAsync(f => f.Id == id)); 
    } 

    private async Task<T> WithContext<T>(Func<Context, Task<T>> func) { 
     if (_autodispose) { 
      using (var c = CreateContext()) { 
       return await func(c); 
      } 
     } 
     else { 
      return await func(_context.Value); 
     } 
    } 

    private static Context CreateContext() { 
     var c = new Context(); 
     c.Configuration.LazyLoadingEnabled = false; 
     return c; 
    } 

    public void Dispose() { 
     if (_context.IsValueCreated) 
      _context.Value.Dispose(); 
    } 
} 

Примечание: я сохранил логику удаления простой для иллюстрации; вам, возможно, придется снова работать с вашими disposed битами.

Ваших методов запросов по-прежнему простые однострочечники, и клиент может легко настроить поведение удаления по мере необходимости, и даже повторно использовать Repository экземпляр в авто-удалении ситуаций:

var repo = new Repository(autodispose: true); 
var fileTask = repo.GetFile(id); 
var filesTask = repo.GetAllFiles(); 
var productsTask = AllProducts(); 
var versionsTask = repo.GetVersions(); 
var termsTask = repo.GetTerms(); 

await Task.WhenAll(fileTask, filesTask, productsTask, versionsTask, termsTask);