Anybody who doesn't have something like mail_safe [1] installed is asking for trouble, no matter where he stores his business logic.
That's a nice solution to the "emails gone wild" problem, but - no offense - it's a bit besides the point.
We could just as well be talking about S3 data, facebook posts, tweets, anything with (side) effects beyond the active database record in question.
I tried to pick a very contrived example. The architecture rails forces you to have is great if all of your business logic is simply CRUD. Once your app starts doing other things though, that's where careful consideration is needed as to where that logic should live.
You could imagine callbacks or observers that do all sorts of things:
ping an external service
touch another model or models
send an internal email
or does a combination of a bunch of stuff.
Things get even tougher when you start having flags that turn logic on or off. It has the potential to really become a mess, very fast.
Re:Where the logic hides in rails apps
by FuzzyDunlop on Sunday December 23, 2012 @03:37PM
(#4960574)
If using Rails, then by default the environment specific config will (I believe) print emails to the log instead of actually sending them.
I could easily imagine someone unaware of this hook running a test to create a bunch of user entries, sending emails all over the place without even realizing.
It's like someone read http://en.wikipedia.org/wiki/COMEFROM and took it seriously.