Hi,
In the spirit of keeping most of the business rules in the buiness objects as part of the CSLA framework, I am trying to use the System.Web.Mail functionality in ASP.NET 2.0 to send an email to a user indicating that a requests they have submitted has changed status.
I currently identify that change in status by looking for certain values in combination in my business object which inherits BusinessBase.
Normally you need to include an 'imports' command in your code. When you do that in the object, it understands importing 'System.Web' but does not give the option of 'System.Web.Mail' .
If I do the imports at the aspx page level code and look to action the email as a change in the value of a dropdown, it understands Systems.Web.Mail.
Perhaps its a dumb question, but why is the above the case? Should automatic creation/sending of emails be located in the business object or the web page?
System.Web.Mail does appear to be in System.Web.dll. So you need to make sure you are add a reference to System.Web for the project you're adding this logic to. You probably have another assembly referenced that has elements in the System.Web namespace, which is why you can say "using System.Web" but not "using System.Web.Mail". For mail you need System.Web.dll.
For sending the emails - think about the use cases - if I change status, I want an e-mail to be sent. It's business logic - you're going to want this behavior within the business layer.
Chris
In my example above, I am actually wanting an email to be sent regardless of whether it is a windows based client accessing the object or a web based client. The choices I felt were to either send the email when a dropdownlist value was selected in the client application or when the value changed in the business object as a result of the the value being selected in the dropdown list
Thanks guys for all the above responses
Just to follow up -
I think especially given your notes about it occuring through Web or Windows - I think it belongs in the business layer. I do not think that "side effects of unit testing" should affect the architecture of your app.
With respect to including System.Web.dll or what have you in a business class library, it has nothing to do with breaking encapsulation. Zero, nada. Will most people find a need to include System.Web in their business class library? Probably not. But we happen to use the ASP.Net Membership and Role API as our standard authentication and authorization for our application - we're building a Web application but there's no reason why we need to have a separate security scheme for Windows (we wouldn't want that!)
In the case where behavior varies between UI's, it depends on specs as to how to proceed - but for example Caching will work differently in Web than Windows for us - in this situation, we have leveraged the provider design and happen to have a WebCacheProvider for our current UI (Web) understanding that what we do for Web is not applicable for Windows. But our business library invokes the CacheManager - part of the business library (which looks at the config file to determine which CacheProvider to leverage).
Chris
skagen00:
I think especially given your notes about it occuring through Web or Windows - I think it belongs in the business layer. I do not think that "side effects of unit testing" should affect the architecture of your app.
![Indifferent [:|]](/emoticons/emotion-8.gif)
I'm not sure what you mean about load - a sent e-mail is a sent e-mail. I sure hope it doesn't take a lot of effort to send e-mails because I would start to feel sorry about all these spammers. ;)
Sending an e-mail from the business layer doesn't need to be synchronous, too.
Bottom line is that if someone wants a "notification if a record has changed" - I don't want to be coding that accomodation in my Win UI, my Web UI, and Web Services UI.
Anyways, I think we'll have to agree to disagree here!
I'm not sure what you mean about load - a sent e-mail is a sent e-mail. I sure hope it doesn't take a lot of effort to send e-mails because I would start to feel sorry about all these spammers. ;)
Sending an e-mail from the business layer doesn't need to be synchronous, too.
True, but then you add complexity. Do you have to handle the AsyncCompletedCallback? I don't know, I can't find anything in the docs one way or another. What happens if the sending fails, and the mail MUST be sent? Do you retry? You have to inform the user at some point. A down mail server can cause a lot of problems.
Bottom line is that if someone wants a "notification if a record has changed" - I don't want to be coding that accomodation in my Win UI, my Web UI, and Web Services UI.
I agree! That's why I advocated SSNS or I guess in Sql 2008, SSRS. SSNS was great because it handled failures and automatically retried, was easily extensible, could handle digest or multicast delivery and a host of other things. SSNS worked basically by running queries you define to detect changes in data, and then generated notifications based on that data. No need to code anything into your application at all, SSNS handled it all for you.
I suppose so; like I said, its unfortnate SSNS is being discontined, otherwise I'd suggest you check it out.Anyways, I think we'll have to agree to disagree here!
I have a table in my DB where I store the data for emails that need to be sent.
Then I have a separate scheduled task which runs every 10 minutes (or whatever interval the client defines) which processes the records in this email table and sends them. This separates the 2 activities and the offline task is free to take as much time as it needs to talk to the mail server. The offline task can also log information about each email it sends - ncluding the fact that the mail server might be down.
Joe
![Wink [;)]](/emoticons/emotion-5.gif)
I use a web service for sending emails which simplifies the async. It isn't critical for my app if the email doesn't send. I am intrigued by this SSNS though. Are there any good articles out there on it?
Copyright (c) Marimer LLC