Сохранение данных в базе данных SQL Server, а затем отправка электронной почты позже

У меня есть форма ввода и редактирования данных, и при каждом событии ввода или обновления данных я должен отправлять электронное письмо динамическому списку получателей. Я отправляю электронное письмо, как только пользователь нажимает кнопки сохранения или редактирования, но думаю сначала сохранить данные в базе данных, а затем отправить электронное письмо позже. Я хочу сделать это частично, чтобы улучшить время отклика приложения, поскольку отправка электронной почты обычно занимает больше времени, чем хотелось бы.

Кто-нибудь сделал что-то, связанное с этим, есть ли лучший способ реализовать что-то подобное или кто-нибудь знает хороший учебник по этому поводу.

Тело письма имеет формат html.


person StackTrace    schedule 29.09.2010    source источник
comment
Почему отправка занимает много времени? вы отправляете получателю? Попробуйте сделать доп в директорию для захвата, а затем попросите MTA отправить оттуда.   -  person TomTom    schedule 29.09.2010
comment
TomTom - я отправляю получателям, я пробовал отправлять асинхронно, но это не делало и не различало.   -  person StackTrace    schedule 29.09.2010


Ответы (3)


Я согласен с ck по поводу использования службы и очереди сообщений, но есть несколько альтернатив.

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

Вы также можете сделать это непосредственно в базе данных, используя либо триггер базы данных, либо запланированное задание в базе данных. Последние версии SQL Server поддерживают выполнение хранимых процедур, написанных на C# или Vb.Net, поэтому вы, вероятно, могли бы повторно использовать здесь большую часть существующего кода.

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

person Rune Grimstad    schedule 29.09.2010
comment
Руна Гримстад - я пытался отправить отдельный поток в своем приложении asp.net, но это как-то не имеет никакого значения - person StackTrace; 29.09.2010
comment
я думаю, что я мог бы серьезно рассмотреть триггер базы данных или запланированное задание в базе данных - person StackTrace; 29.09.2010
comment
Как вы начали новую тему? Я думаю, что это должно работать, если вы используете метод ThreadPool.QueueUserWorkItem. Ссылка: haacked.com/archive/ 09.01.2009/ - person Rune Grimstad; 29.09.2010

Вы можете написать службу Windows, которая обрабатывает отправку ваших электронных писем, а затем использовать очередь сообщений в качестве метода передачи данных из вашего приложения в службу. т.е. ваше приложение сохраняет данные, а затем добавляет сообщение в очередь. Служба постоянно опрашивает очередь сообщений, отправляя каждое из них по электронной почте.

person cjk    schedule 29.09.2010
comment
Или вы пропускаете очередь сообщений (отдельная установка, часто недоступная) и используете сервисный брокер (такая же функциональность на сервере sql). - person TomTom; 29.09.2010

Один из способов сделать это — записать в базу данных, а затем поместить сообщение в очередь, которая сообщает почтовой службе (записанной как служба Windows), что есть электронные письма для отправки. Затем служба электронной почты взаимодействует с базой данных, чтобы выяснить, что ей на самом деле нужно сделать. Это отделяет службу электронной почты от веб-приложения, а также позволяет избежать опроса.

Это немного отличается от решения ck тем, что сообщение очереди используется в качестве триггера, а не содержит информацию об электронной почте. Это в некоторой степени разделяет веб-приложение и службу электронной почты и означает, что служба электронной почты может повторно использоваться несколькими клиентами, при этом каждому клиенту не нужно соблюдать (и идти в ногу) один и тот же формат сообщения электронной почты.

person HTTP 410    schedule 29.09.2010