Почему практика возврата Task<T> из методов Web Api не по умолчанию и в методах, которые вы получаете при создании нового Web Api Controller в Visual Studio?Недостатки методов Web Api, возвращающих задачи
Есть ли недостатки для этого?
public class MyController : ApiController
{
public Task<string> Boo()
{
return Task.Factory.StartNew(() =>
{
return "Boo";
});
}
}
Когда использовать асинхронные операции:
Task, этот случай является ключом к масштабируемым приложениям, так как ваши потоки не блокируются в ожидании внешних источников.С этим, как говорится, мы не всегда используем асинхр: http://msdn.microsoft.com/en-us/magazine/hh456402.aspx
Типичный случай мы не должны запрашивать данные из внешних источников, это уже есть:
Это может на самом деле принести пользу разработчику, чтобы избежать использования асинхронных методов в определенном небольшом наборе прецедентов, особенно для библиотечных методов , доступ к которым будет осуществляться более мелкомасштабным образом. Как правило, это тот случай, когда известно, что метод может фактически выполнить синхронно, потому что данные , полагающиеся на уже имеющиеся.
асинхронные операции с Task действительно есть накладные расходы:
При проектировании асинхронных методов, рамочные разработчики потратили много времени оптимизации прочь распределения объектов. Это связано с тем, что распределения представляют собой одну из самых больших затрат на производительность в инфраструктуре асинхронного метода . Акт выделения объекта обычно довольно дешевый. Выделение предметов сродни заполнению вашей корзине с товарами, в том, что вам не стоит много усилий по размещению предметов в вашей корзине; это когда вы на самом деле проверяете , что вам нужно вытащить свой кошелек и инвестировать значительные средства . В то время как ассигнования обычно дешевы, полученная мусорная коллекция может быть шоу-шоу, когда дело доходит до приложения..
Есть ли недостатки для этого?
Да, вы делаете свой код менее удобочитаемым, более продолжительным и менее совершенным без уважительной причины. Я не вижу преимуществ этого.
Возможно, стоит отметить, что Task.Factory.StartNew на самом деле не является асинхронным в том смысле, который вы хотите (то есть выпустите поток); он просто работает на фоновом потоке, поэтому не дает никакой реальной выгоды, он просто увеличивает накладные расходы. Если вы все время пытались вернуть задачу, вы можете использовать Task.FromResult, который просто заставит ваш метод работать полностью синхронизироваться. И тогда вам нужно спросить себя, почему вы пытаетесь сделать его более подробным и менее понятным. – Frans