Есть функция обработки данных, которая требует определенное количество времени для исполнения.Поэтому вызываем функцию в отдельном Thread из пула. Но и там же нужно получить данные из БД.
Получается следующая конструкция, которая роботает, но мне не нравится:
Так делать не надо, никогда не делайте асинхронные обертки для синхронных методов, caller может сам создать Task или вызвать метод из уже созданного. Просто сделайте синхронный метод, если используются синхронные методы для доступа к бд.
I>
Снова не правильно. Чтобы получить результат вызова асинхронного метода см. Task.Result (есть нюансы с контекстом). В частности ваш метод можно переписать как-то так:
private void WorkFunc()
{
var dat1 = MyRequestToBDAsync1().Result; // ждем
var dat2 = MyRequestToBDAsync2().Result; // ждем
NeedLongTime(dat1, dat2);
}
Проще всего сделать методы MyRequestToBD...() синхронными и вызывать их последовательно.
Если запросы 1 и 2 можно выполнить одновременно, то имеет смысл вызывать их паралельно, к примеру:
Здравствуйте, Sinatr, Вы писали:
S>Снова не правильно. Чтобы получить результат вызова асинхронного метода см. Task.Result (есть нюансы с контекстом). В частности ваш метод можно переписать как-то так:
S>
S>Ну вообще то у Command полно асинхронных методов
У меня проблема не что использовать, а как использовать.
Проблема в том, что в Worker Thread вызывается async функция. Получается плохой код, который хотелось бы исправить.
S>Так делать не надо, никогда не делайте асинхронные обертки для синхронных методов, caller может сам создать Task или вызвать метод из уже созданного. Просто сделайте синхронный метод, если используются синхронные методы для доступа к бд.
У меня немного другая конструкция. После return стоит await и если я правильно понимаю, то UI thread будет ждать завершения функции не блокируясь. Это больше относится к примеру ниже.
Но в этом случае как быть вот с этим, здесь пишут что надо делать именно так (пример RenderAsync).
Кто прав?
S>Снова не правильно. Чтобы получить результат вызова асинхронного метода см. Task.Result (есть нюансы с контекстом). В частности ваш метод можно переписать как-то так: S>
Result не рекомендуют использовать из-за опасности нарваться на deadlock. Хотя в этом случае выполнение идёт в worker thread, a не в UI thread, поэтому такой опасности скорей не будет.