Where does sending emails go? Service layer or web layer?

Question

I've been having this design-pattern problem for weeks. Where do I put the logic for sending emails? Behaviors can be accessed through the asp.net mvc web interface or through a wcf endpoint hosted inside the asp.net app.

Here are the features of the app:

1. Email notifications.
2. Template rendering - This means I have to know the url structure (actions, base address, etc).

Currently, I am storing base url and paths inside the web.config file and having this email service inside the service layer.

One particular feature is sending confirmation emails to the user and sending the generated confirm url to them. (no idea how to generate this url from the service layer)

Answer 1

Emails should never ever ever ever be served from the web layer. You never want a user to wait while an email is sending.

The best thing to do is create a persistent email queue ( sql is fine ) which another job accesses to send the email. This gives you the ability to re-send failed emails and run them completely outside your web request thread.

Answer 2

What jfar say is true; that said, you could use Postal to generate your emails and then store those emails in a database, again, as jfar suggests.

From the postal website:

Postal lets you create emails using regular MVC views.

That means you'll have an Email folder under your Views folder; those views are actually your email templates and have full access to all Html and URL helpers any other view has which will probably make it easy for you to generate a confirm URL or whatever it is that you may need.

Postal includes and IEmailService interface with a concrete EmailService implementation. This service allows you to directly send an email message or, even better, generate a regular MailMessage object. You could then just store the ready-to-go email in a table on your db and send it later on with a background job.