Да, я думаю, что F # может быть весьма полезным для асинхронного программирования в этом сценарии. Если вы хотите правильно написать свой асинхронный код, вам нужно использовать методы BeginFoo / EndFoo или API на основе событий, чтобы избежать блокировки потока пользовательского интерфейса при выполнении какого-либо асинхронного вызова. В результате вы не можете писать код в обычном последовательном стиле - просто выполняя одну операцию за другой. Вместо этого вам нужно обернуть все в обратные вызовы, которые содержат отдельную обработку исключений.
В F # вы можете использовать асинхронный рабочий процесс, который скрывает все «обратные вызовы» и автоматически переносит все в обработчики исключений. В результате вы можете написать асинхронный код, который выполняет несколько вызовов, в качестве последовательного кода и использовать все обычные конструкции потока управления (такие как try, for, while, ...). Вы можете написать:
let processData(userInputs) = async {
try
let! temp = Service.AsyncDoSomething(userInputs)
let! res = Service.AsyncDoSomethingElse(temp)
return res
with e ->
// Handle exception
Это вызывает операцию DoSomething асинхронно и перемещает оставшуюся часть функции в обратный вызов, который выполняется после завершения операции (и аналогично для DoSomethingElse). Однако обработка исключений может быть записана обычным способом. Эта функция также удобна для записи некоторых взаимодействий с пользовательским интерфейсом (см., Например, этот пост SO или запись моего F # выступления в London User Group )
Недостаток использования F # для этого проекта в том, что он не имеет прямой поддержки WCF. Вы, конечно, можете использовать его, но вам придется писать изменяемые классы в стиле C #, что выглядит не очень хорошо - хорошим вариантом может быть использование библиотеки C # и определение там необходимых необходимых вещей WCF (а затем просто использование это из F #).