Когда использовать asyn c в библиотеках generi c? - PullRequest
Новая
       32

Когда использовать asyn c в библиотеках generi c?

0 голосов
/ 07 февраля 2020

Недавно я искал хороший пример универсального шаблона репозитория c, и меня смутила совершенно другая топи c. Async await. Это упрощенный интерфейс: 

public interface IGenericRepository<TEntity> where TEntity : class
{ 
    Task<TEntity> GetById(int id);
}

, и это два примера реализации этого интерфейса:

A: 

public async Task<TEntity> GetById(int id)
{
    return await _dbContext.Set<TEntity>()
                .AsNoTracking()
                .FirstOrDefaultAsync(e => e.Id == id);
}

B: 

public Task<T> GetById(int id) => Context.Set<T>().FindAsync(id);

В обоих случаях это метод из обобщенного c RepositoryBase класса, который будет наследоваться реальными Repository классами. В одном случае async await используется, во втором не . Почему?

и последующий вопрос: если есть разница, когда мы должны использовать async await, когда мы должны просто вернуть Task?

1 Ответ

4 голосов
/ 07 февраля 2020

Недавно я искал хороший пример шаблона репозитория generi c

Шаблон репозитория generi c обычно считается антипаттерном, именно потому, что он слишком универсальный c , Лично я предпочитаю стиль абстракции уровня данных в виде портов и адаптеров, который позволяет приложению определять необходимые ему методы DAL. Хотя во многих случаях прямой EF работает нормально (это, пожалуй, самый распространенный выбор).

В одном случае используется asyn c await, во втором - нет. Почему?

Есть несколько соображений относительно того, когда elide async / await. Это в основном сводится к обработке исключений. Методы, возвращающие задачи, должны помещать исключения для этих задач, а не вызывать исключения напрямую; это неявный контракт для методов с асинхронными сигнатурами.

Итак, этот код будет (некорректно) генерироваться напрямую, если Context или Set<T> throw: 

public Task<T> GetById(int id) => Context.Set<T>().FindAsync(id);

Как правило, сохранение async / await является безопасным выбором; их устранение является незначительной оптимизацией производительности, которую следует выполнять только после с учетом ловушек .

...