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

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

подробней:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как извне указать Content-Encoding
...
Рейтинг: 0 / 0
20.08.2014, 12:13
    #38724309
Нахлобуч
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EmailSender в asp.net mvc
17-77а ваш Postmark и есть "планировщик"/"очередь", только вне рамок реализуемой системы, определитесь уже - нужен он или нет Разницу между "планировщиком" и "очередью" понимаешь?
...
Рейтинг: 0 / 0
20.08.2014, 12:43
    #38724362
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EmailSender в asp.net mvc
НахлобучА вот это --
МСУПрисаживайся, двойка. 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
20.08.2014, 12:44
    #38724370
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EmailSender в asp.net mvc
НахлобучИ вот тут планировщик не подходит абсолютно, от слова совсем.

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

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

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

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


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