none
async методы vs обычные RRS feed

  • Вопрос

  • Всем доброго дня!

    Подскажите, пожалуйста, границы применения асинхронных методов.

    Судя потому, что пишет официальный msdn - можно смело в массовом порядке писать асинхронные экшены и асинхронные методы сервисных классов, напрочь вытесняя обычные.

    Но в чем подвох?

    Есть ли какие нибудь рекомендации в каких случаях нужно применять то или другое?

Ответы

  • Да, в целом так и есть. "К тому же: никаких негативных факторов асинхронность в себе не несет." - за исключением сложности кода (как бы не старались разработчики платформы и насколько просто это не выглядело бы). А так да, асинхронность – это хорошо в тех приложениях где много невычислительных операций (операций ввода-вывода проходящих параллельно).

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Vladimir Rog 26 мая 2014 г. 10:41
    Модератор

Все ответы

  • Подвох есть – сложность  и вероятность неправильного применения. Коротко скажу так: они нужны для маштабируемых и высоконагруженных приложений, иначе от их применения практической пользы нет. Посмотрите этот топик до конца, там раскрыта тема, зачем всё это вообще нужно.

    Сделаем содержимое сообщества лучше, вместе!

    Модератор
  • Тему прочитал от и до.

    Как я понял еще из мануалов и Ваш топик немного это подтвердил, если совсем кратко:

    async методы позволяют не стопить приложение, ожидающее когда они выполнятся, а запускаться в асинхронном режиме, не забивая пул потоков IIS сервера.

    А значит при больших нагрузках (подразумевается: большое количество одновременных подключений ) у приложения появляется больше шансов выжить.

    Мой вывод.

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

    Итого: любое нормальное боевое (не "Hello World") веб-приложение - нужно делать по возможности максимально асинхронным.

    К тому же: никаких негативных факторов асинхронность в себе не несет.

    Что скажете?

  • Да, в целом так и есть. "К тому же: никаких негативных факторов асинхронность в себе не несет." - за исключением сложности кода (как бы не старались разработчики платформы и насколько просто это не выглядело бы). А так да, асинхронность – это хорошо в тех приложениях где много невычислительных операций (операций ввода-вывода проходящих параллельно).

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Vladimir Rog 26 мая 2014 г. 10:41
    Модератор