Асинхронная синхронизация по сети с общим интерфейсом

Question

Я понимаю, что мы должны избегать асинхронной синхронизации и наоборот. Вот два сообщения от Stephen Toub, объясняющие это красиво:

• Should I expose asynchronous wrappers for synchronous methods?
• Should I expose synchronous wrappers for asynchronous methods?

Мы используем WCF для общения между уровнями и имеют общий контракт, используемый как сервисом и клиентом. Для создания прокси и канала клиент использует ChannelFactory<TContract>. Одно из преимуществ этого заключается в том, что нам не нужно вручную обновлять наши [многие] ссылки на службы, и мы получаем автоматическую проверку времени компиляции с обеих сторон, если интерфейс изменился. Однако это также означает, что мы не можем поддерживать синхронный интерфейс на стороне сервера (не возвращая Task<Result>), а также иметь асинхронный клиентский прокси (возврат Task<Result> из-за сетевого хопа).

Так что мой вопрос в том, есть ли какой-либо реальный вред/недостаток, чтобы иметь контрактный тип возврата Task<Result>, а на серверной стороне просто сделать return Task.FromResult(SyncCode());? Мы эффективно выполняем асинхронную синхронизацию на стороне сервера, чтобы включить async на стороне клиента, но в любом случае сеть технически уже асинхронна. Task.FromResult() не должен создавать никаких дополнительных потоков или вводить существенные накладные расходы. Это похоже на разумное исключение из правила?

Другими словами, я, возможно, реализацию, подобный следующему:

public PersonResult GetPerson(int id) 
{ 
    return SyncCode(); 
} 

public Task<PersonResult> GetPersonAsync(int id) 
{ 
    return Task.FromResult(GetPerson(id)); 
} 

Answer 1

Мой пример кода не позволяет службе активировать, так как добавление Async считается то же имя метода. Ошибка была: «Не может быть двух операций в одном и том же контракте с тем же именем, методы GetPersonAsync и GetPerson в типе ... нарушают это правило».

Из этого сообщения об ошибке я нашел лучшее решение здесь: https://stackoverflow.com/a/28635558/177333. У вас есть синхронный интерфейс для реализации на стороне сервера и создания производного интерфейса, который добавляет async для клиентской стороны. Поскольку WCF игнорирует Async в имени при отправке сообщения по сети, вы вызываете один и тот же метод в любом случае.

Answer 2

Task.FromResult() не следует создавать дополнительные потоки или внести существенные накладные расходы. Это похоже на разумное исключение ?

Нет, это не разумное исключение (если у вас есть выбор), так как это вредит масштабируемости вашей службы WCF. В ваших интересах использовать естественно асинхронные API-серверы, если они доступны.

Что касается клиента, не имеет значения, определяет ли ваш метод интерфейса контракта WCF как PersonResult GetPerson(int id) или Task<PersonResult> GetPersonAsync(int id). Клиент будет работать в любом случае, даже без перекомпиляции прокси-сервера WCF. Для получения дополнительной информации:

• Different forms of the WCF service contract interface.

Асинхронность в клиенте WCF полностью независима от асинхронности в службе WCF. Как правило, вы хотите использовать асинхронность с обеих сторон, но по разным причинам: поддерживать отзывчивость пользовательского интерфейса в клиентском приложении и увеличить пропускную способность на стороне сервера.Для получения более подробной информации:

• Calling async methods from a WCF service.