1

I'm creating a service layer for my WPF app that will wrap a web API client that uses Action<T> callbacks for it's asynchronous methods. Since I'm going to need to wrap the methods anyway, I was considering making my wrapper methods of my service layer conform to the new Task-based async pattern of .NET 4.5, rather than expose Action<T> callbacks.

I don't currently have a pressing need for Task-based async, but I also don't have any reason that I necessarily have to stay with the callbacks and wrapping seems easy enough (as described here) Backwards compatibility isn't an issue. That said, if there are any pitfalls to such Action<T> callbacks to Tasks wrapping, I'll just maintain the status quo.

Community
  • 1
  • 1
HolySamosa
  • 9,011
  • 14
  • 69
  • 102
  • 1
    just bear in mind that a you always have to catch exceptions thrown by a task befor disposing the task (i.e. try-catch around the Task.Wait methods or similar) else you will get a runtime exception in release builds! – eFloh Aug 23 '12 at 08:27

1 Answers1

3

I do not see any pitfalls with doing this, in fact it opens your application to allot more flexible scenarios. I would suggest you also look at converting some of your "call back" scenarios to a the observer pattern (see Reactive Extensions project by Microsoft) which, when combined with the Task-based pattern, is so much more powerful and flexible. And of course you will be able to use your new new Task-based pattern with the new async/await-pattern in C# 5.0!

Hope it helps.

Francois Nel
  • 1,662
  • 2
  • 19
  • 29