System.Net.Mail, create a new object just for mailling? Encapsulation question

ltgrady posted on Thursday, August 21, 2008

I have an alert system in my application where we save users messages to one another in our SQL database.  Now our users would like us to start emailing notifications for those messages. 

I have a Message object and MessageRecipient objects and a collection to hold them. These are CSLA objects that I use to create a new message, set subject, body, and other properties and then add recipients to the MessageRecipients child collection.  All of our data is stored in sql database and then we have other methods that show these messages on our users Alert pages.

So now I need to have some kind of .SendEmailNotifications method that is going to use the System.Net.Mail to take these properties and recipients and send the emails.  I'm trying to decide where to put this.  Whether I should add a static method to the Message class, Message.SendEmailNotifications that checks the recipients properties to see if they recieve email alerts or not and then sends the emails.  Or, should I create some kind of Mailer object that has properties Subject, Body, etc. and then has .AddEmailRecipient(userID) method to add email reciepients, then finally a .SendEmail method to send it all.

So should I keep it in my existing Message object or create a seperate Mailer object?  What do you think?

richardb replied on Friday, August 22, 2008

I've previously created a seperate class library for this sort of thing so it can be re-used across many projects.

So I have my wrapper class around the System.Net.Mail and then versions of SendMessage methods that can take a simple string, or message object, etc. 

 

ltgrady replied on Monday, August 25, 2008

That's where I was going but as I began writing the wrapper it just seemed like I was writing the same class but just renaming the methods.  All it really did was store a few things like my smtp credentials.  I suppose that may be enough to justify a new class, not having to deal with that.  I'm still not sure.

richardb replied on Tuesday, August 26, 2008

That's true, but you never know how Microsoft might change things in the future and wrapping the functionality in your own class might help reduce the upgrade effort later.