У меня есть репозиторий с методом Insert
, который возвращает int
(методы и типы здесь не актуальны). Я думаю создать synchronous
и asynchronous
методы вставки этого репозитория. Для метода asynchronous
целесообразно заключить метод synchronous
Insert
в task
во избежание дублирования кода?создавать асинхронные и синхронные методы для репозитория
ответ
Нет, это не очень хорошая практика, о чем подробно Microsoft Стивена Toub здесь:
... и Стивен Клири здесь:
http://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html
длинная история Короче говоря, если весь ваш метод завершает синхронный вызов в Task.Run
, это тривиально, и я уверен, что вызывающий абонент вполне способен сделать это сам. Нет необходимости увеличивать площадь вашего API, если у вас нет естественной асинхронной операции (или если вы не знаете, что в будущем вы сможете ее предоставить, и, следовательно, хотите, чтобы потребители таргетировали метод XxxAsync
с первого дня).
В качестве бонуса, вот реальный пример жизни методов обертки асинхронных удаляются из популярной библиотеки:
Json.NET используется для обеспечения SerializeAsync
и DeserializeAsync
методы, которые были просто обертками вокруг их синхронных аналогов с использованием Task.Factory.StartNew
. В конечном итоге они были устаревшими, поскольку они не добавляют ценность API и считаются потенциальной проблемой масштабируемости. Полное обсуждение, которое привело к этому изменению можно найти здесь:
вот сценарий: я реализую этот репозиторий в веб-api. Метод api - асинхронный. Из предоставленной вами ссылки я понял, что это не нормально для того, чтобы обернуть некоторый код в Task.Run, так как действовать в этом случае? Предположим, что код перекоса - это атомная инструкция ... –
@BudaGavril, в сценариях, где вы * должны * предоставить метод «Задача» из-за конструктивных ограничений есть два варианта в зависимости от whet ее потребители могут терпеть блокирующий вызов. В веб-API они могут, из-за уже асинхронного характера транспорта. Поэтому, если ваш метод не содержит никаких других операций async (но должен возвращать «Задачу»), вы просто выполняете свою работу, как обычно, и возвращаете 'Task.FromResult (...)' в конце. В ситуациях, когда блокировка действительно вызовет проблему для потребителя, используйте «Task.Run», во что бы то ни стало. –
P.S. На самом деле это гораздо более интересный вопрос, чем заданный. Подумайте о том, чтобы опубликовать его как отдельный вопрос, в комплекте с примером кода. Я едва поцарапал поверхность в своем комментарии выше. –
Вы должны написать свой метод асинхронного с нуля, используя асинхронную версию всех доступных методов (например, если вы используете Entity Framework - вам должны использовать FirstAsync(), SaveChangesAsync и т. д. – Evk