I thought about the serialization thing a little more and figured out a way to handle the situation where notification needs to be sent when changes are made to the database. There are two ways to handle this.

Message Queuing - This is exactly the sort of thing queuing is for. It guarantees that you message gets to all the destinations so you can put a message on the queue and the queue reader for the database change with post the update to the database and the email queue reader will shoot an email to the appropriate recipients.

Email Service - Providing an email service in your business layer would allow you to make the database update and then fire off an email through an email service you create. The queuing option is probably more reliable but may involve a learnign curve.

There are probable other options out there but I want to mention that email is inherently unreliable unless you have a mechanism for ensuring delivery and SQL Server can't do that very well. This does not take into account the reliability of SQL Mail. I have had enormous amounts of trouble with SQL Mail and I highly recommend that it not be used for applications. It is fairly stable if you're just sending alerts from SQL Server and SQL Agent but relying on it for business needs is not a good idea. If you have the capability to monitor the event log, I would not even use SQL Mail at all; just make sure that critical alerts are posting to the Windows Event Log.