Forum: Ruby on Rails Should controllers be "smart"?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pat M. (Guest)
on 2006-05-05 02:21
(Received via mailing list)
I'm working on a small project with a friend, and one of the things we
needed to do was send off an email whenever someone signs up an
account.  His implementation was pretty simple - throw a
deliver_welcome call inside the controller after the signup.  I'm sure
that this is a pretty common thing to do.

The problem, in my mind, was that the app now became tied to two
places - the controller and model - for handling business logic.  What
do I mean?  Well if I open script/console and do

Account.register(...)

Then no email is sent.  According to our business rules, a welcome
email should be delivered whenever an account is registered.  With his
implementation, the only way to correctly register an account is to do
it through the controller.

So what do you guys think about this?  In my opinion I should only
have to type one command in console to make everything happen
(Account.register), and the controller should call the exact same
code, and only set up page info, error messages, etc.

One thing I'd like to point out is that if I send the email from
within Account.register, now the Account class gets tied to
ActionMailer and ActionPack.  That seems pretty crappy too, really,
and I actually posted about that maybe a month ago.  My solution was
to create a new Message model and have a separate app occasionally
poll the db to mail out messages, using the account_id to build the
message.

To boil it down, do you think you should be able to manage your
application 100% through your domain model if you so desire?

Pat
Scott B. (Guest)
on 2006-05-05 05:36
(Received via mailing list)
On May 4, 2006, at 6:19 PM, Pat M. wrote:

>
> One thing I'd like to point out is that if I send the email from
> within Account.register, now the Account class gets tied to
> ActionMailer and ActionPack.  That seems pretty crappy too, really,
> and I actually posted about that maybe a month ago.  My solution was
> to create a new Message model and have a separate app occasionally
> poll the db to mail out messages, using the account_id to build the
> message.

You could put the delivery in an observer that fires on create.  This
way it's not tightly coupled to the model, and if you want to create
accounts without firing off email, just don't instantiate the observer.

>
> To boil it down, do you think you should be able to manage your
> application 100% through your domain model if you so desire?

Absolutely


-Scott
This topic is locked and can not be replied to.