Подводные камни переноса асинхронных методов обратного вызова в асинхронные методы задачи?

Я создаю сервисный уровень для своего приложения WPF, который будет обертывать клиент веб-API, использующий Action<T> обратные вызовы для своих асинхронных методов. Поскольку мне все равно нужно будет обернуть методы, я подумал о том, чтобы мои методы-оболочки моего сервисного слоя соответствовали новому асинхронному шаблону .NET 4.5 на основе Task, а не выставляли Action<T> обратные вызовы.

В настоящее время у меня нет острой необходимости в асинхронизации на основе Task, но у меня также нет причин, по которым я обязательно должен оставаться с обратными вызовами, и упаковка кажется достаточно простой (как описано здесь) Обратная совместимость не является проблемой. Тем не менее, если есть какие-либо подводные камни для таких Action<T> обратных вызовов для переноса задач, я просто буду поддерживать статус-кво.


person HolySamosa    schedule 23.08.2012    source источник
comment
просто имейте в виду, что вам всегда нужно перехватывать исключения, выдаваемые задачей, перед удалением задачи (т. е. try-catch вокруг методов Task.Wait или подобных), иначе вы получите исключение во время выполнения в релизных сборках!   -  person eFloh    schedule 23.08.2012


Ответы (1)


Я не вижу никаких подводных камней в этом, на самом деле это открывает ваше приложение для выделения более гибких сценариев. Я бы посоветовал вам также обратить внимание на преобразование некоторых ваших сценариев обратного вызова в шаблон наблюдателя (см. Реактивные расширения проект Microsoft), который в сочетании с шаблоном на основе задач становится намного более мощным и гибким. И, конечно же, вы сможете использовать свой новый шаблон на основе задач с новым шаблоном async/await в C# 5.0!

Надеюсь, поможет.

person Francois Nel    schedule 23.08.2012
comment
Другой вариант для асинхронных потоков — TPL Dataflow. - person Stephen Cleary; 23.08.2012