DHH: Think of emails as views delivered through SMTP | Hacker News Reader

DHH: Think of emails as views delivered through SMTP

loudthinking.com

36 pointsrufo7 comments

Doesn't this all just depend on specific needs? At Poll Everywhere we have an email that gets fired off if a poll is close to filling-up. If we put this logic in controllers it would be madness considering that we accept votes via SMS, Web, etc. Instead we fire off the notification as a callback on our Poll model after a vote is received.

On the other hand, when a user signs up at PE, we fire that email off via the controller. There are certain times in our application where we don't want to send an email out simply when a new User model is created.

This seems like a silly argument; just do what works best for your app. Is an email a view? Use it in your controller. Is your email an asynchronous notification? Maybe it belongs in your model.

Indeed. I have a Rails app running with some fairly complex object relationships, along with several notifications that potentially need to be sent out if any one of the objects is updated.

Considering the how many entry points could trigger a notification, the controller would be an insane place to put these, even with a mixin. An observer seems a far better place for that type of message.

I think the problem of where to put them stems from having applications as an MVC 'stack', as jrockway said in a sibling thread. Assuming that there is only one input/output point in a web-app is not very realistic. It seems that these applications might fit better in a hexagonal architecture[1], but Rails doesn't really support apps like that, so you have to cram mailers in where you can.

[1] http://c2.com/cgi/wiki?HexagonalArchitecture

I can attest to that. We walked down the "One MVC" stack idea which simply doesn't work if an application has various modalities like Email, SMS, and Twitter. It turns out Rails view/controller stack is awesome for web applications, but only web applications.

For different modalities, like Email, SMS, or Twitter interactions, do NOT attempt to hack it into rails; rather, reuse the models defined in a Rails project and implement or use a different view/controller stack better suited for those environments.

The post is a direct response to:

http://www.robbyonrails.com/articles/2009/11/16/sending-emai...

Discussed here:

http://news.ycombinator.com/item?id=944686

That was always the way I thought about emails in Ruby on Rails.. Multipart itself makes you focus on the "template" aspect of an email. When you're done with it, there's rarely a need to have any complicated business logic associated with the action, other than triggering or queueing the delivery.

The real take-away here is how poorly suited MVC is to web applications.

Reply on news.ycombinator.com