Возврат или ожидание задания <T>в WCF - PullRequest
Новая
       16

Возврат или ожидание задания <T>в WCF

0 голосов
/ 03 мая 2018

Допустим, у меня есть служба WCF Websocket: 

[ServiceContract(CallbackContract =typeof(ICallback))]
public interface ISomeInterface
{       
    [OperationContract]
    string GiveMeString();
}

Теперь, на стороне клиента, благодаря WCF я также имею в своем распоряжении метод GiveMeStrignAsync. Теперь я хочу создать клиентский API, который использует такие асинхронные методы, созданные WCF. Есть два способа сделать это: 

public  Task<string> GiveMeStringAsync()   //method on client side
{
   Task<string> task = null;
   try
   {
      task = ServiceReference.GiveMeStringAsync();
   }
    catch (Exception ex)
   {
      Console.WriteLine(ex.Message);
   }
   return task;       
}

Тогда я буду ждать этого метода.

Или возможно используйте await внутри этого метода: 

public async Task<string> GiveMeStringAsync()   //method on client side
{
   string s = String.Empty;
   try
   {
      s = await ServiceReference.GiveMeStringAsync();
   }
   catch (Exception ex)
   {
      Console.WriteLine(ex.Message);
   }
   return s;       
}

Мои вопросы:

  1. Как я правильно понимаю, async / await, во втором примере мне все еще нужно где-то ждать этот метод, так что будет больше ожидающих. Больше ждет результатов в снижении производительности?

  2. Допустим, я прав, и вариант № 1 - это путь. Что делать, если на моей стороне клиента у меня есть оболочка для этого API (не имеет значения, почему). В этом классе-обёртке я все еще должен возвращать (не ожидать) Task и использовать await только один раз при вызове метода класса-обертки (который вызывает метод API)?

1 Ответ

0 голосов
/ 03 мая 2018

Похоже, что вам нужно это сообщение от Microsoft об этом, но я постараюсь подвести итог на основе того, что вы спросили:

Есть ли еще ожидаемое снижение производительности?

Если вы измеряете только одну нить. Единственная причина, по которой вы ожидаете задачу, состоит в том, что долгое ожидание не блокирует другую работу, которую вы могли бы выполнять одновременно.

Как вы собираетесь await Метод Task, который не помечен async? Есть и другие соображения, которые вы должны учитывать, такие как: вы действительно ожидаете, что try / catch будет работать без этого await? Это, вероятно, не будет.

Простой ответ - просто подождать / асинхронно и не забывать об использовании CancellationToken s и, возможно, .ConfigureAwait(false);, где это уместно.

...