Question

I’ve been in some discussion recently about where email (notifications, etc…) should be sent in an ASP.NET MVC application. My nemesis grin argues that it only makes sense that the email should be sent from the controller.

I argue that an email is simply an alternate or augmented view through a different channel. Much like I would download a file as the payload of an ActionResult, the email is simply delivered through a different protocol.

I’ve worked an extension method that allows me to do the following:

<% Html.RenderEmail(model.FromAddress, model.ToAddress, model.Subject); %>

which I actually include within my the view that is displayed on the screen. The beauty is that, based on convention, if I call RenderEmail from a parent view named MyView.ascx, I attempt to render the contents of a view named MyViewEmail.ascx, unless it is not found, in which case I simply email a copy of parent view.

It certainly does make it testable (I still have an ISMTPService injected for testing), I wondered if anyone had any thoughts on whether or not this breaks from good practice. In use it has been extremely handy when we needed to easily send an email or modify the contents of the emailed results vs the browser rendered results.

Thanks,

Hal

Answer 1

Your “nemesis” is correct.

The job of the view is to send HTML to the client, and nothing else. It has no business sending email.

You should send the email inside the controller.

If you want to render a view to the email, you can render it like this:

var viewData = new ViewDataDictionary<T>(data);
var viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, "ViewName");

using (var writer = new StringWriter(CultureInfo.InvariantCulture)) {
    ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, viewData, new TempDataDictionary(), writer);
    viewResult.View.Render(viewContext, writer);

    viewResult.ViewEngine.ReleaseView(ControllerContext, viewResult.View);

    return writer.ToString();
}