НахлобучhVosttдобавляете задание шедулеру, в шедулере реализуете обработку очереди и отправку писем.Планировщик-то тут зачем? Разовая же акция.
Не согласен. Не известна реальная нагрузка на сайт, чтобы утверждать, что это "разовая акция". На сайте могут в течении минуты сотни, тысячи заявок создаваться. У них могут меняться статусы и прочие атрибуты, на это так же нужна реакция. Самый правильный способ - способ, предложенный hVostt.

P.S. По теме вопроса UserManager<TUser, TKey>.SendEmailAsync (вот тут в красках http://codearticles.ru/articles/2460)

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

P.S. hVostt, спс

НахлобучМожно, конечно, воткнуть какую-нибудь MSMQ (или RabbitMQ, или ZeroMQ, или еще что-нибудь), написать отдельный Windows Service, который будет выполнять всю бэкэндную работу и возгордиться крутой архитектурой, но ТСу этого сейчас не надо.
Так об этом и речь. Нужна отдельная песочница для процессинга, а что это будет, вин сервис, вин шедулер или кварц - дело десятое.

НахлобучНе нужно заниматься интеллектуальным онанизмом и придумывать решения несуществующих проблем.

НахлобучНагрузка будет мизерная, более чем уверен.

Шедеврально.

НахлобучМСУУ них могут меняться статусы и прочие атрибуты, на это так же нужна реакция.Об этом в исходном сообщении вообще ни слова не было сказано.
Предположить это запрещает религия? В исходных сообщениях, обычно, мало что оговаривается. И если такое понадобится (а такое понадобится) - это отлично ляжет в архитектуру email процессора.

НахлобучМСУСамый правильный способ - способ, предложенный hVostt.Дык нет же. Планировщик тут не нужен.
Еще как нужен. Банально по каким-то сетевым или иным причинам обвалилась отправка конкретного письма. Всё, жуём траву на лугу? Тебе бы код писать, а не архитектурой заниматься :)

НахлобучМСУP.S. По теме вопроса UserManager<TUser, TKey>.SendEmailAsync (вот тут в красках http://codearticles.ru/articles/2460) Безотносительно текущей задачи -- это прэлэстно, я считаю. Мало того, что отправка писем -- совершенно ортогональная по отношению к Identity Management функциональность, так еще и API традиционно придуман индусами-укурками.
Что значит "безотносительно текущей задачи"? Безотносительно текущей задачи могу предложить тебе форум кухарок. А относительно текущей задачи, UserManager.SendEmailAsync отличное решение. В API не увидел никакого ужаса, удобный инструмент, раз в 500 удобнее, чем древний унылый мембершип.

НахлобучНи заголовков, ни вложений, ни альтернативных представлений, ни кодировок.
Присаживайся, двойка. IIdentityMessageService .

НахлобучМСУЕще как нужен. Банально по каким-то сетевым или иным причинам обвалилась отправка конкретного письма. Всё, жуём траву на лугу? Тебе бы код писать, а не архитектурой заниматься :)И вот тут планировщик не подходит абсолютно, от слова совсем.
Тут планировщик подходит как нельзя кстати. Абсолютно как нельзя кстати.

НахлобучЕсли делать надежную систему отправки уведомлений, то, очевидно, должна быть БД отправляемых уведомлений и очередь, в которую с засовывают сообщения (от слова Message из Message Queue) типа "отправь уведомление #113247".
Во-первых, очередью может быть обычная таблица в БД. Во-вторых, можно ничего этого не делать, а уведомлять по признаку в БД. Признаком может быть любая логическая конструкция в соответствии с требуемой бизнес логикой. Начиная от смены статусов заявки, кончая какими-то иными типами. И никакие очереди тут даром не нужны. После успешной отправки сообщения выставляется флаг отправленного уведомления. Никакой магии, конструкция проста как мир и надежна, как камень.

НахлобучМСУВ API не увидел никакого ужаса, удобный инструмент, раз в 500 удобнее, чем древний унылый мембершип.Удобный для песочницы, да. Еще раз повторяю: отправка писем -- совершенно ортогональная по отношению к Identity Management функциональность.
Десятый раз говорю, ASP.NET Identity имеет самое прямое отношение к отсылке сообщений. Почему? Потому что есть встроенный внятный функционал. И если автору всё-таки захочется отправить сообщения прям из сайта по месту, то это самый подходящий вариант сделать это. При условии, что используется ASP.NET Identity, разумеется.

Нахлобуч Установить заголовок. Например, List-Unsubscribe, который для каждого типа письма свой и должен передаваться извне

Добавить формируемые извне же вложения

Отправить письмо одновременно в HTML и в Plaintext

Как извне указать Content-Encoding

Легко.

1. IIdentityMessageService.SendAsync => MailMessage.Headers.Add("List-Unsubscribe", "< http://www.host.com/list.cgi?cmd=unsub&lst=list>, <mailto:list-request@host.com?subject=unsubscribe>";
2. IIdentityMessageService.SendAsync => MailMessage.Attachments
3. IIdentityMessageService.SendAsync => MailMessage.AlternateViews
4. IIdentityMessageService.SendAsync => MailMessage.BodyEncoding

skyANAhVosttпропущено...
Выходи из судорга и прекращай нести бред. А в чём бред-то заключается? У нас около 12 миллионов писем в месяц примерно по такой схеме отправляются.
Бред заключается вот в этом "И вот тут планировщик не подходит абсолютно, от слова совсем."

Как организовывать рассылку, очередью или признаком - не суть дело. Оба варианта имеют право на жизнь. И планировщик тут вполне вписывается в архитектуру.

НахлобучМСУТут планировщик подходит как нельзя кстати. Абсолютно как нельзя кстати.Ну расскажи, куда ты его собрался втыкать.
Так вроде уже рассказывал. Втыкать я его собрался в вин сервис рассылки уведомлений. Сервис крутится по определенному расписанию и шлет письма. За основу реализации расписания можно взять тот же кварц.

НахлобучМСУВо-первых, очередью может быть обычная таблица в БД.И этот человек тут рассуждает про "нагруженные системы". Polling плохо -- это раз. Locking для "select for update" -- это два. Катастрофически разная производительность операций insert/select/delete при таком сценарии работы -- три. Любой из этих пунктов положит твою "нагруженную" систему на лопатки.
Ого, давненько так не отжигали на форуме фантазёры. Ну ладно, по-порядку. Polling плох чем и в контексте чего? Откуда Locking на чтение, с дубу рухнул? Срочно читать про изоляции транзакций, недавно одному неучу рассказывал про Lock:Escalation. При правильных индексах и прямых руках у тебя CRUD будет просто летать, а не то, что тормозить. Так что попробуй испугай кого-нибудь другого лопатками.

НахлобучМСУВо-вторых, можно ничего этого не делать, а уведомлять по признаку в БД. Признаком может быть любая логическая конструкция в соответствии с требуемой бизнес логикой. Начиная от смены статусов заявки, кончая какими-то иными типами. И никакие очереди тут даром не нужны. После успешной отправки сообщения выставляется флаг отправленного уведомления. Никакой магии, конструкция проста как мир и надежна, как камень.Это опять какие-то пустопорожние сказки.
Допустим, наступило какое-то условие -- заявка переведена из статуса А в статус Б. Ты отправляешь уведомление, отправка обламывается. Твои действия?
Это не сказки, это простое решение задачи. По твоему примеру,
1. Заявка переведена из статуса А в статус Б
2. Устанавливается флаг "Оповестить" для уведомления подписчикам (отдельная таблица со ссылкой на заявку)
3. Сервис уведомлений согласно расписанию опрашивает флаги этой таблицы и на основе них делает рассылку
4. Письмо выслано, устанавливается флаг в соответствующее значение "Уведомление выслано"
5. Письмо не выслано, устанавливается флаг значение "Ошибка", пишется текст ошибки

НахлобучМСУASP.NET Identity имеет самое прямое отношение к отсылке сообщений. Почему? Потому что есть встроенный внятный функционал. И если автору всё-таки захочется отправить сообщения прям из сайта по месту, то это самый подходящий вариант сделать это. При условии, что используется ASP.NET Identity, разумеется.Этот функционал печален и уныл. Identity не менее печален. Microsoft уже показало свою несостоятельность в этом вопросе -- сначала стандартная система авторизации и аутентификации в ASP.NET, потом Membership, потом Identity -- всё это проектировалось и писалось вообще без оглядки на то, как оно должно использоваться.

А IIdentityMessageService -- это какой-то огрызок.
Огрызок - это то место, которое не думает и не пытается анализировать. IIdentityMessageService - это внятный механизм подключения сервиса сообщений. Причем, можно легко использовать two factor messages.








Так что твои унылые потуги надругаться над ASP.NET Identity идут в лес. Поплачь в другом месте.

НахлобучОтправь мне из метода Signup() письмо со вложением и в двух форматах.
Пристыкуй для менеджера свой IIdentityMessageService и рассылай хоть корову в мешке.

НахлобучhVosttНа кой ляд городить это говнище в коде с созданием каких-то тасков в контроллере? Что с этим убожеством делать потом? Как сопровождать?Таски я не предлагал, привет.
Ты предложил прямо по месту отправить сообщение, "Разовая акция". Как это может коррелировать с более или менее внятной архитектурой? Произошла ошибка отправки. Дальше что делать с твоей разовой акцией?

НахлобучhVosttНо вообще, это не требуется. Для массовой рассылки с погремушками нужны другие инструменты и планировщик для этого подходит более чем.Ты точно внимательно читал? Какие массовые рассылки?

Ты читаешь посты попой?

RDS1) Пользователь вносит заявку, заполняя поля формы;
2) Нажимает кнопку Сохранить;
3) Запускается действие контроллера, там заявка сохранятся в базе через репозиторий.
4) .... и теперь надо разослать копии писем всем заинтересованным лицам...

Нахлобуч, "заинтересованных лиц" может быть сотня, тысяча. Ты собираешься этот делать такую отправку прям из контроллера? Ты сдурел?