2016-11-18 2 views
0

У меня есть репозиторий с методом Insert, который возвращает int (методы и типы здесь не актуальны). Я думаю создать synchronous и asynchronous методы вставки этого репозитория. Для метода asynchronous целесообразно заключить метод synchronousInsert в task во избежание дублирования кода?создавать асинхронные и синхронные методы для репозитория

+0

Вы должны написать свой метод асинхронного с нуля, используя асинхронную версию всех доступных методов (например, если вы используете Entity Framework - вам должны использовать FirstAsync(), SaveChangesAsync и т. д. – Evk

ответ

4

Нет, это не очень хорошая практика, о чем подробно Microsoft Стивена Toub здесь:

https://blogs.msdn.microsoft.com/pfxteam/2012/03/24/should-i-expose-asynchronous-wrappers-for-synchronous-methods/

... и Стивен Клири здесь:

http://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html

длинная история Короче говоря, если весь ваш метод завершает синхронный вызов в Task.Run, это тривиально, и я уверен, что вызывающий абонент вполне способен сделать это сам. Нет необходимости увеличивать площадь вашего API, если у вас нет естественной асинхронной операции (или если вы не знаете, что в будущем вы сможете ее предоставить, и, следовательно, хотите, чтобы потребители таргетировали метод XxxAsync с первого дня).

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

Json.NET используется для обеспечения SerializeAsync и DeserializeAsync методы, которые были просто обертками вокруг их синхронных аналогов с использованием Task.Factory.StartNew. В конечном итоге они были устаревшими, поскольку они не добавляют ценность API и считаются потенциальной проблемой масштабируемости. Полное обсуждение, которое привело к этому изменению можно найти здесь:

https://github.com/JamesNK/Newtonsoft.Json/issues/66

+0

вот сценарий: я реализую этот репозиторий в веб-api. Метод api - асинхронный. Из предоставленной вами ссылки я понял, что это не нормально для того, чтобы обернуть некоторый код в Task.Run, так как действовать в этом случае? Предположим, что код перекоса - это атомная инструкция ... –

+0

@BudaGavril, в сценариях, где вы * должны * предоставить метод «Задача» из-за конструктивных ограничений есть два варианта в зависимости от whet ее потребители могут терпеть блокирующий вызов. В веб-API они могут, из-за уже асинхронного характера транспорта. Поэтому, если ваш метод не содержит никаких других операций async (но должен возвращать «Задачу»), вы просто выполняете свою работу, как обычно, и возвращаете 'Task.FromResult (...)' в конце. В ситуациях, когда блокировка действительно вызовет проблему для потребителя, используйте «Task.Run», во что бы то ни стало. –

+0

P.S. На самом деле это гораздо более интересный вопрос, чем заданный. Подумайте о том, чтобы опубликовать его как отдельный вопрос, в комплекте с примером кода. Я едва поцарапал поверхность в своем комментарии выше. –

 Смежные вопросы

  • Нет связанных вопросов^_^