Building a Email Sender Service

Question

I have a couple of web applications which all utilize sending emails whether it be by contact form, or some kind of notification updates etc.

The problem I have found is that there isn't really any way to track the emails which are being sent from the web applications, so I've come up with a possible solution:

It's pretty straight forward really - instead of having each web application sending the emails themselves I would like to unify the process by creating a central Email Sender Service.

In basic terms, each application would just create a row in a 'Outbound Emails' table on the database with To,From,Subject,Content data.

The Email Sender Service (Win Service) would then pick the emails from the outbox, send them and then mark as sent.

---

Even though I would store 'basic email' information (to,from,subject,content) in the database, what I would really like to do is also store the 'MailMessage' object itself so that the Email Sender Service could then de-serialize the original MailMessage as this would allow any application to fully customize the email.

Are there any problems with using the MailMessage object in this way?

Update: Another objective, is to store a log of emails that have been sent - hence the reason for using a database.

Magulac

Answer 1

A far better architecture is to have the applications call some sort of public interface on the send email service. The service itself can then be responsible for recording send in a database.

This architecture means that the database becomes internal to the service and so reduces the coupling between your applications (each application knows about a relatively small public contract rather than a database schema). It also means that if you do find some problem with storing MailMessage objects in the database then you can change the storage method without updating all of your clients.

Milline

I like this idea actually! I could have a hosted WCF service for the Email Sender, and the web applications could point to that instead and the WCF can handle putting the email into database (for logging) and for sending out the email immediately. – Magulac

Answer 2

Why use the database? Simply have the applications call your email service directly, providing all information.

If you'd like to queue up the sends, then you can use a net.msmq binding with WCF, which will store the requests in a reliable queue that the service would read from. All of this would be done for you.

Harslet

Sorry John, I didn't make it clear that I actually want to see some form of a log of all the emails that have been sent. I know you can trawl through SMTP logs for this if need be but I find that rather cumbersome compared to a database table. I think using a WCF as you mentioned is the way to go :) – Magulac

@Dal: go ahead and use a database to log, but I'd use WCF directly to send the request to the service. – Harslet