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.
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.