Немного о странных архитектурных решениях
Сейчас у меня основная работа связана с разработкой софтинки на ASP.NET. Во время разработки оной, наткнулся на весьма неприятную штуку, которая теоретически должна была облегчить жизнь всяким программистам, а на самом деле является весьма спорной и даже вредной.
Описание задачи: в .NET framework есть клиент SMTP. Письма он умеет посылать синхронно и асинхронно. Во втором случае можно подкинуть callback, который вызовется со статусом операции. Нужно посылать письма асинхронно, причем хотелось минимальными усилиями. Ну чего нам стоит вызвать SendAsync() вместо Send()? А оказалось, что не все так просто.
Начиная с ASP.NET 2.0 (сейчас на дворе 3.5), разработчики ввели поддержку асинхронных операций в базовый функционал. Но при этом сделали достаточно странное предположение - программе всегда нужен будет результат асинхронной операции до отдачи ответа клиенту. В результате, они сделали такой вот велосипед - программист может запустить несколько асинхронных задач, используя стандартные средства .NET, а страница будет ждать, пока они не завершатся. Кроме того, они запретили (кидается исключение) использование асинхронных задач, если для страницы не поставить флажок Async=”True”.
В целом, подход достаточно странный - у нас бизнес логика лежит в отдельных assembly, и посылка писем оттуда же. Получается, что для отсылки писем асинхронно, через стандартное API, мне прийдется менять уровень представления (хотя бы флажок Async=”true” повесить на все нужные страницы). Что как бы эээ.
Вот такие вот дела.
P.S. Если использовать асинхронную посылку писем вне контекста запроса ASP.NET, то все работает нормально.
