MVC: Where to trigger user registration emails

I am building an MVC application (using the Zend Framework).

When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:

• In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.

• But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.

• Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my mode开发者_Python百科l a little more 'fine grained'.

I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.

Your thoughts are most appreciated!

---

According to Zend Framework's definition of MVC, you should put send the email from the controller:

Controllers...decide which view to display based on the user's request.

Models, on the other hand, contain:

...basic functionality behind a set of abstractions.

An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."

---

In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.

In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.

---

You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.

This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.

Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.

Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.

Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.