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

НахлобучПлюс советуемый МСУ UserManager<TUser, TKey>.SendEmailAsync Method подразумевает, что пользователь зарегистрирован на сайте. Очень смелое допущение.
А кто говорил, что SendEmailAsync - серебряная пуля? Это простое решение "по месту" шлёпнуть сообщение из сайта. У способа есть и минусы и плюсы. К тому же, я акцентировал своё внимание именно на отдельной песочнице и шедулере, а не на SendEmailAsync. Еще раз спрашиваю, ты каким местом читаешь топик?

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

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

Внимание вопрос, откуда Буч узнал про десяток-другой получателей?

НахлобучPolling плох в контексте БД. Расходование ресурсов на поддержание ACIDности.
Запретим БД. Вообще. Будем помнить всё в уме. Так? Не устал фантазировать на пустом месте?

НахлобучМСУОткуда Locking на чтение, с дубу рухнул?Расскажи, как ты будешь добиваться того, чтобы одно и то же уведомление не отправлялось из всех потоков (или процессов), в которых работают отправлятели уведомлений.
Расскажи, откуда ты взял, что у меня будет несколько отправителей уведомлений? Отправитель уведомлений один и работает он в одном процессе и в одном потоке. А задачи на рассылку он может ставить асинхронно. Например, получил 1 тыс подписчиков, раскидал задачи на 10 тредов и вперед. Что тут ты собрался синхронизировать? Каждый тред не зависит от друг друга, полностью автономная работа. Чего ты там опять куришь?

НахлобучМСУПри правильных индексах и прямых руках у тебя CRUD будет просто летать, а не то, что тормозить. Индексы мешают вставкам и удалениям, их отсутствие мешает поиску, что, в свете предыдущего пункта, мешает вставкам.
В архитектуре статусов ничего удалять не нужно. Поэтому именно эта архитектура более гибка и поддерживаема, чем очередь.

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

НахлобучМСУIIdentityMessageService - это внятный механизм подключения сервиса сообщений. Причем, можно легко использовать two factor messages.Это ограниченный механизм, предназначенный только для отправки всяких околоайдентитьных сообщений. Больше он ни на что не годен.
И тем не менее, он имеет право на жизнь. И говорить о том, что его нельзя использовать в простых сценариях, глупо. Точно так же глупо, как говорить о том, что ASP.NET Identity убогое гавно.

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

НахлобучМСУНахлобуч, "заинтересованных лиц" может быть сотня, тысяча. Ты собираешься этот делать такую отправку прям из контроллера? Ты сдурел? Нет, их не сотня и не тысяча. Какой смысл отправлять даже сотне человек уведомление о том, что кто-то создал заявку?
Откуда ты знаешь, сколько подписчиков должно быть? Ты генератор требований? Что значит, какой смысл отправлять сообщение сотне человек? Они подписаны на ресурс, значит их нужно уведомить. У нас в конторе есть портал на шарепоинте, есть списки и библиотеки документов сотрудников, на которые подписаны участники. Их количество достигает более 1 тыс на популярных библиотеках (приказы, документы по поставщикам, юридическая информация и так далее). Всего в компании немногим менее 10 тыс человек. Если ты там сидишь и работаешь в коморке с 3 калеками, то это не значит, что не может быть большое число подписчиков.

НахлобучМСУпропущено...
А кто говорил, что SendEmailAsync - серебряная пуля? Это простое решение "по месту" шлёпнуть сообщение из сайта. У способа есть и минусы и плюсы. Самое простое -- это SmtpClient. Тащить весь остальной шлак для "по месту" нет никакой необходимости. И плюсов у "способа" нет.
Так в SendEmailAsync и используется SmtpClient, включи уже голову.

НахлобучЧто тут тебя так развеселило?
Твоя тупость. Серьезно.

НахлобучМСУпропущено...
Запретим БД. Вообще. Будем помнить всё в уме. Так? Не устал фантазировать на пустом месте?По делу будет что-то?
Вот именно, по делу что-то будет? Или будешь дальше писать о страшилках использования БД?

НахлобучМСУРасскажи, откуда ты взял, что у меня будет несколько отправителей уведомлений? Отправитель уведомлений один и работает он в одном процессе и в одном потоке. А задачи на рассылку он может ставить асинхронно. Например, получил 1 тыс подписчиков, раскидал задачи на 10 тредов и вперед. Что тут ты собрался синхронизировать? Каждый тред не зависит от друг друга, полностью автономная работа. Чего ты там опять куришь?Отличненько, уже какие-то потоки пошли в дело. Откуда они возьмутся, если "уведомлений один и работает он в одном процессе и в одном потоке"? Какие задачи, кому он их ставит?
Так ты сам начал про "процессы и потоки". А теперь меня обвиняешь в этом. Странный ты. Не "уведомлений один", а "Отправитель уведомлений один". Почувствуй разницу. С чего ты решил, что должно быть несколько отправителей уведомлений.
Вот твой высер, если что:

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

Как объяснишь свой вопрос?

Еще раз, "отправлятель уведомлений" один. А рассылка уведомлений может идти асинхронно в несколько независимых потоков. Что не понятного я сейчас сказал?

НахлобучМСУВ архитектуре статусов ничего удалять не нужно. Поэтому именно эта архитектура более гибка и поддерживаема, чем очередь.Опять какие-то голословные утверждения.
Что именно голословно утверждено и почему? Будешь приводить аргументы или просто какать в форум невнятными формулировками?

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

НахлобучА если тексты уведомлений формировать непосредственно в момент наступления событий, то всех этих проблем с консистентностью можно избежать.
Зачем заранее формировать тексты и, тем более, хранить их где-то? Это же феерический бред, дублирование и просто антипаттерн. И ты что-то собрался нам рассказывать об архитектуре?

НахлобучМСУИ тем не менее, он имеет право на жизнь. И говорить о том, что его нельзя использовать в простых сценариях, глупо.Глупо его использовать в сценариях, для которых он вообще никак не предназначен. Отправка уведомлений о событиях, не связанных с Identity, -- один из них.
Сценарий только один - отправка сообщения пользователю с темой и телом сообщения. Для этого вполне можно использовать нативный механизм ASP.NET Identity. В чем проблема? Кто запрещает?

НахлобучМСУЧто за бред? Каких поступлений, какой бизнес? Что ты несешь? ))Я не пойму, что тебя так смешит. Автор пишет софт для удовлетворения каких-то бизнес-потребностей. Если недоставка некоторых уведомлений не является проблемой, то можно остановиться на самом простом работающем решении -- отправка "по месту". Если же бизнес потребует "доставки любой ценой", то нужно будет думать отдельно.
Автор конкретно спросил совета. Ты посоветовал глупость. Делать массовую отправку сообщений по месту в контроллере - удел кретина, а не программиста или архитектора. С этим согласен? И бизнес тут не причем, не нужно его сюда примешивать. Бизнес ничего не знает и не должен знать об архитектуре рассылки уведомлений.

НахлобучМСУОткуда ты знаешь, сколько подписчиков должно быть? Ты генератор требований?Нет, я просто знаю, что в случае, когда от человека требуется какая-то деятельная реакция (а именно она нужна в ответ на уведомление о поступление новой заявки), размазывать ответственность по сотне человек никто не будет.
Ну это только твои фантазии, которые не подкреплены практикой. С рабочими процессами в системах электронного документооборота работал? Рассказать про такой классический воркфлоу, как "Согласование документа"?

НахлобучМСУЧто значит, какой смысл отправлять сообщение сотне человек? Они ... это не значит, что не может быть большое число подписчиков.Молодец, похвастался. Дальше что? Как это относится к теме?
Это аргумент того, что твои утверждения про то, что "не может быть более 20 подписчиков" - наглая ложь. И даже в случае 20 подписчиков отправлять им сообщения "по месту" в контроллере - беспощадное зло. Согласен?

НахлобучМСУТак в SendEmailAsync и используется SmtpClient, включи уже голову.Вот правда -- и что с того? Он прячет его за убогим API, не добавляя никакой ценности. Абсолютно. Просто прослойка.
Так весь фреймворк - прослойка, которая что-то где-то прячет. Ценность твоих сообщений в данном топике ниже плинтуса. В чем суть твоего бытия тут? Просто зашел покакать напалмом?

НахлобучМСУпропущено...
Твоя тупость. Серьезно.Браво.
Ок.

RDSСкажите имеет ли право на реализацию такой вариант. Я напишу консольное приложение, которое будет подключаться к базе и смотреть какие письма стоят в очереди и будет их рассылать. Данное приложение будет запускаться через определенные промежутки времени планировщиком задач Windows'а??? Я думаю мне бы такой вариант подошел как нельзя лучше! Кто, что думает?
Да, нормальный рабочий вариант.

17-77Зависит от бизнеса, будет требование слать все уведомления - значит надо их генерить сразу и сохранять где либо до момента отправки
Не в коем случае.

1. Каждое изменение статуса заявки логируется в отдельную табличку (ID, ID заявки, Статус заявки, Дата/Время, Флаг процессинга). Можно дополнить дополнительной информацией при необходимости. Напр., ID пользователя, Сообщение об ошибке и т.д.
2. Песочница, которая процессит рассылку, анализирует эту таблицу и отсылает письма. Текст письма берется из некоего шаблона, который хранится где угодно.

Сохранять готовые сообщения по факту для последующих рассылок - это избыточность и мазохизм.

17-77Я бы не завязывался на планировщик винды, а сделал бы свою вин-службу на кварце, как в самом первом ответе в теме
+1