Здравствуйте, Vladek, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Ох сколько вопросов сразу:
G>>1) В случае List<T> надо все синхронные операции в async\await оборачивать?
V>Тривиальная задача.
Так и запишем — лишняя работа.
Кстати что SaveChangesAsync будет в этом случае делать? Как гарантировать в тестах что он вызывается, если мы изначально делаем на List<T>, а потом "подменяем storage"?

G>>2) В случае базы данных вместо одного апдейта в базу улетит 100500?
V>Не обязательно. Скорее всего, не важно.
Скорее всего очень важно. Примерно на два порядка будет отличаться время работы в зависимости от реализации.

G>>3) Откуда вообще у веб-сервиса метод с фильтрами по категории или будут тянуться все сотрудники, а потом фильтр пойдет на клиенте?
V>Метод с фильтрами по категории у нашего репозитория, а как он реализован — дело десятое. Главное, код работы с зарплатой от этого никак не зависит.
Во-во и на практике приведёт к тому, что будет затягиваться вес список и фильтроваться на клиенте. А потом этот потрясающий get-метод ктонить использует на главной странице и приложением станет невозможно пользоваться.

G>>У вас получился заведомо неэффективный код для каждого из случаев И сразу же отрублены все возможности улучшить ситуацию.
V>Что такое "эффективный код" в случае изменения важной информации о сотрудниках предприятия?
Эффективный код, который не делает лишней работы или соотношение лишней или доля лишней работы крайне мала. Чем он занимается — неважно, потому что имеется тенденция распространения стиля на все приложение. То что кажется в одном месте маленькой неэффективностью копируется в другое место, где появляются тормоза на несколько десятков секунд.

Не знаю как ты, а я все это уже проходил. За каждым из приведенных выше вопросов стоит косяк в реальной программе, который привел к реальным потерям.