Does sending an email belong in the presentation layer or business layer of an application?

I am trying to figure out the best area to place code to send an email in my Asp.net MVC application. Right now my application is setup in 2 VS projects separating out the business layer from the presentation 开发者_如何学Pythonlayer. I am trying to setup a situation that when a user reset's their password, after the business logic changes the password the server will send an email to the user with their newly generated password.

Should I be calling the code to send the email (including data on how the email looks) from the business layer (after the business layer resets the password) or in the presentation layer (after the business layer returns a successful result)?

Sending emails should be part of the business layer.

I came across the same issue few weeks ago ,,, I am building a web application using asp.net mvc 3 that consists of three projects : Repository (DAL), Services (BLL) , Presentation (Web)

My application logic is implemented at the service layer so I was searching for the best way to implement a completely independent module at the service layer for sending HTML emails to the users so that that my service layer functions can use it directly without having to bring it up to the presentation layer.

After some searching I found an elegant solution that was done by Kazi Manzur where he created an email subsystem that makes use of Razor Views to send HTML/Text emails outside of the web proejct.

Use Razor for Email Template outside ASP.NET MVC

I have been using his subsystem since then and it has been doing a great job.

I partially agree with BobTodd because he's suggesting you abstract it out. The only part where I (partially) disagree is about it going in the business layer.

Sending email is dependent on some sort of physical implementation - and you don't want to tie your BL to outside dependencies related to some email provider.

In a small project you could include it in the BL, I guess, to keep things simple but I'd be in favor of abstracting it out completely, in which case I'd treat it just like i'd treat data Access.

In my view of the world there's two places you could put it:

• As a shared service that you might want to call from anywhere - and because it would be abstracted out you'd be able to.
• As / via a "External Service Adaptor", which is also abstracted out but only accessible from the BL - which might in turn expose methods that anything (like the UI) could call (if you really wanted to).

Note: Self promotion alert! - taken from one of mine own articles: http://morphological.wordpress.com/2011/08/29/5-layer-architecture/

Sending an email does not belong in the presentation layer, however a "dedicated presentation layer" can be used to determine what the email looks like (design, theme and etc).

Each "layer" can actually consist of several independent assemblies.
E.g. you can have more than one View.

I prefer to think of things as components, that can be switched out using dependency injection.

Create an IEmailService interface with a concrete implementation in your business layer.

Have it injected into your controller.

Have the Controller create and generate the view (the email from a template) with the Model and call the IEmailService implementation to actually send it.

IEmailService then becomes easily mockable when testing your controller.

Sending an email is business layer functionality. You would have a mailhandler class with a method that will send the message and handle exceptions.