powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / EmailSender в asp.net mvc
25 сообщений из 71, страница 1 из 3
EmailSender в asp.net mvc
    #38722931
RDS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RDS
Гость
Ребят, поделитесь опытом. Как реализовать отправку Email наиболее правильно, реализуя следующий сценарий:
1) Пользователь вносит заявку, заполняя поля формы;
2) Нажимает кнопку Сохранить;
3) Запускается действие контроллера, там заявка сохранятся в базе через репозиторий.
4) .... и теперь надо разослать копии писем всем заинтересованным лицам...
Где это надо делать? Там же в методе(action) контроллера? Или в методе создать объект Task, и в параллельном потоке пускай делает рассылку?
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723045
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RDSГде это надо делать?

добавляете задание шедулеру, в шедулере реализуете обработку очереди и отправку писем.

подробней:

http://www.quartz-scheduler.net/

http://stackoverflow.com/questions/6647272/how-to-setup-quartz-net-for-scheduling-emails

...
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723468
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttдобавляете задание шедулеру, в шедулере реализуете обработку очереди и отправку писем.Планировщик-то тут зачем? Разовая же акция. Очередь же тут была бы к месту, но тащить целую очередь ради банальной отправки писем десятку-другому получателей считаю несколько чрезмерным.

RDS, не усложняй сейчас параллельными потоками, репозиториями и прочей мишурой. Отправляй всё как есть, в контроллере. И очень рекомендую использовать Postmark .
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723536
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучhVosttдобавляете задание шедулеру, в шедулере реализуете обработку очереди и отправку писем.Планировщик-то тут зачем? Разовая же акция.
Не согласен. Не известна реальная нагрузка на сайт, чтобы утверждать, что это "разовая акция". На сайте могут в течении минуты сотни, тысячи заявок создаваться. У них могут меняться статусы и прочие атрибуты, на это так же нужна реакция. Самый правильный способ - способ, предложенный hVostt.

P.S. По теме вопроса UserManager<TUser, TKey>.SendEmailAsync (вот тут в красках http://codearticles.ru/articles/2460)
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723548
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучПланировщик-то тут зачем? Разовая же акция.

Дело не в "разовости" акции, а в том, что время отправки электронной почты не детерменировано (тем более куче адресатам). В задачу веб-сервера входит как можно быстрее обработать запрос и вернуть ответ пользователю. Ещё раз подчеркну, как можно быстрее . Поэтому лучше отдать отправку писем шедулеру.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723550
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723556
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttВ задачу веб-сервера входит как можно быстрее обработать запрос и вернуть ответ пользователю.разве в случае Task это будет не так?
Да, будет израсходован один фоновый поток веб-сервера, но зато не надо лишних телодвижений (при небольшой, понятно, нагрузке отправки почты)
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723618
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.ProДа, будет израсходован один фоновый поток веб-сервера, но зато не надо лишних телодвижений (при небольшой, понятно, нагрузке отправки почты)
Два потока на реквест - это жирно для нагруженных систем. Если тебя устраивает такой подход и кол-во писем в минуту стремится к нулю, делай так. Но я бы не стал применять такой подход. Отдельная песочница для процессинга - это лучшее, что можно предложить.

P.S. hVostt, спс
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723643
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУДва потока на реквест - это жирно для нагруженных систем. Если тебя устраивает такой подход и кол-во писем в минуту стремится к нулю, делай так.Я как раз и спрашивал про низконагруженную (письмами) систему. Ведь как у ТС с этим - мы не знаем.

А почему два потока? Первый же освободится (для приема новых реквестов). Второй не будет из пула потоков для обработки реквестов.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723853
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.Proразве в случае Task это будет не так?
Да, будет израсходован один фоновый поток веб-сервера, но зато не надо лишних телодвижений (при небольшой, понятно, нагрузке отправки почты)

а почему сразу не делать по уму, не понимаю? принцип "так ведь работает же и так" не уместен. делать правильно и хорошо надо превращать в крепкую привычку, тогда потом проблем не будет.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723855
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.ProА почему два потока? Первый же освободится (для приема новых реквестов). Второй не будет из пула потоков для обработки реквестов.

пожалуйста, прочитай посыл топикастера, процитирую на всякий случай кусочек:

авторРебят, поделитесь опытом. Как реализовать отправку Email наиболее правильно

зачем ему подкидывать заведомо не хорошие, не качественные решения? я думаю, что как отправить почту в принципе он итак знает.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723866
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttа почему сразу не делать по уму, не понимаю? принцип "так ведь работает же и так" не уместенВ данном случае я подразумеваю другой принцип - не плодить лишних сущностей. То есть для того, чтобы сделать "по уму", нужно будет внести дополнительную зависимость от сторонней библиотеки, уменьшая надежность, понятность, сопровождаемость системы.

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

А очереди сообщений я организовывал, я понимаю преимущества централизации обработки
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38723916
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.ProhVosttа почему сразу не делать по уму, не понимаю? принцип "так ведь работает же и так" не уместенВ данном случае я подразумеваю другой принцип - не плодить лишних сущностей. То есть для того, чтобы сделать "по уму", нужно будет внести дополнительную зависимость от сторонней библиотеки, уменьшая надежность, понятность, сопровождаемость системы.

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

А очереди сообщений я организовывал, я понимаю преимущества централизации обработки

Просто человек задаётся вопросами как лучше, и как правильно, а не вопросом как отправить почту из контроллера, какой-нибудь одинокий е-мейл, раз в пол года. Речь идёт о поступающих заявках и рассылке, значит дело пахнет жареным
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724014
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttПоэтому лучше отдать отправку писем шедулеру.Ты ж понимаешь, что планировщик сделан для того, чтобы ему можно было сказать "выполни такое-то действие через 45 минут, а вот другое действие выполняй каждые два часа по будням". Ничего из этого в данном случае не нужно. Нужно уметь отложенно (и то это под большим вопросом) отправлять письма. Отправить и забыть, ничего больше не повторять.

Посему, планировщик тут совершенно не в кассу. Можно, конечно, воткнуть какую-нибудь MSMQ (или RabbitMQ, или ZeroMQ, или еще что-нибудь), написать отдельный Windows Service, который будет выполнять всю бэкэндную работу и возгордиться крутой архитектурой, но ТСу этого сейчас не надо.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724016
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНе согласен. Не известна реальная нагрузка на сайт, чтобы утверждать, что это "разовая акция". На сайте могут в течении минуты сотни, тысячи заявок создаваться.Нагрузка будет мизерная, более чем уверен. Не нужно заниматься интеллектуальным онанизмом и придумывать решения несуществующих проблем.
МСУУ них могут меняться статусы и прочие атрибуты, на это так же нужна реакция.Об этом в исходном сообщении вообще ни слова не было сказано.
МСУСамый правильный способ - способ, предложенный hVostt.Дык нет же. Планировщик тут не нужен.
МСУP.S. По теме вопроса UserManager<TUser, TKey>.SendEmailAsync (вот тут в красках http://codearticles.ru/articles/2460) Безотносительно текущей задачи -- это прэлэстно, я считаю. Мало того, что отправка писем -- совершенно ортогональная по отношению к Identity Management функциональность, так еще и API традиционно придуман индусами-укурками. Ни заголовков, ни вложений, ни альтернативных представлений, ни кодировок.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724024
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RDS4) .... и теперь надо разослать копии писем всем заинтересованным лицам...
их много?
нужны ли гарантии отправки письма? вариант1 - отправить один раз и пофик на ошибку отправки, вариант2 - отправить, перехватить ошибку, попробовать еще раз через 5 минут
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724027
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучПланировщик-то тут зачем? Разовая же акция. Очередь же тут была бы к месту, но тащить целую очередь ради банальной отправки писем десятку-другому получателей считаю несколько чрезмерным.

RDS, не усложняй сейчас параллельными потоками, репозиториями и прочей мишурой. Отправляй всё как есть, в контроллере. И очень рекомендую использовать Postmark .
разовая? а ошибки отправки? а ваш Postmark и есть "планировщик"/"очередь", только вне рамок реализуемой системы, определитесь уже - нужен он или нет
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724154
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если нет трудностей - мы их выдумаем
софистика наше все
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724209
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиЕсли нет трудностей - мы их выдумаем
софистика наше все

кого-то ты мне напоминаешь

YouTube Video
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724237
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучМожно, конечно, воткнуть какую-нибудь 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 .
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724305
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЕще как нужен. Банально по каким-то сетевым или иным причинам обвалилась отправка конкретного письма. Всё, жуём траву на лугу? Тебе бы код писать, а не архитектурой заниматься :)И вот тут планировщик не подходит абсолютно, от слова совсем.

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

Обработка транзакционности и ситуации с превышением порогового числа повторов отправки и реакции на это событие компонентов системы остается на усмотрение читателя.

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

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

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

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

Как извне указать Content-Encoding
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724309
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
17-77а ваш Postmark и есть "планировщик"/"очередь", только вне рамок реализуемой системы, определитесь уже - нужен он или нет Разницу между "планировщиком" и "очередью" понимаешь?
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724362
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучА вот это --
МСУПрисаживайся, двойка. IIdentityMessageService .курам на смех. Покажи-ка мне, по пунктам, как мне с помощью этого уныния:

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

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

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

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


Ты из какой берлоги вылез?

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
public class EmailService : IIdentityMessageService
    {
        public Task SendAsync(IdentityMessage message)
        {
            // Plug in your email service here to send an email.
            return Task.FromResult(0);
        }
    }



И отправляй тут хоть Аватара в блю-рей...

Пипец, ну неужели лень хоть немножечко углубиться в тему, прежде чем яростно бросаться в спор? Дожили.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724370
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучИ вот тут планировщик не подходит абсолютно, от слова совсем.

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

Обработка транзакционности и ситуации с превышением порогового числа повторов отправки и реакции на это событие компонентов системы остается на усмотрение читателя.

Выходи из судорга и прекращай нести бред.
...
Рейтинг: 0 / 0
EmailSender в asp.net mvc
    #38724393
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучМСУЕще как нужен. Банально по каким-то сетевым или иным причинам обвалилась отправка конкретного письма. Всё, жуём траву на лугу? Тебе бы код писать, а не архитектурой заниматься :)И вот тут планировщик не подходит абсолютно, от слова совсем.
Тут планировщик подходит как нельзя кстати. Абсолютно как нельзя кстати.

НахлобучЕсли делать надежную систему отправки уведомлений, то, очевидно, должна быть БД отправляемых уведомлений и очередь, в которую с засовывают сообщения (от слова 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
...
Рейтинг: 0 / 0
25 сообщений из 71, страница 1 из 3
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / EmailSender в asp.net mvc
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]