Forum: Ruby on Rails RE: 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.
Chris B. (Guest)
on 2006-05-05 04:14
(Received via mailing list)
I am sure many people have different opinions about this, however in the
strictest sense business logic belongs in the controller.  Along with
the strictness in mind, some people would argue if validation is
business logic or part of the data model.  But I would guess that a
"rich domain model" means all the things needed to maintain data
integrity and, in some cases, to make it easy to get things out of the
data model (by using associations) should be in the model.  But in most
cases, associations and validations are common across all business
logic, so it makes great sense to put those in the data layer.

But a controller is indeed for business logic.  Controllers aren't only
for web access, although they are strongly tied to it in this framework
because it IS a web framework, they can "speak" xml, soap, xml-rpc, and
a host of other ways to allow other applications access through your
controller.

Let's assume that you left your register method inside your Accounts
model.  Let's further assume you just bought up Company xyz and you are
going to take all of their web users and integrate them into your site.
So would you still use your register method with your standard email
that says "Thanks for registering on our website..."?  This might
confuse people because, after all, they didn't register, they were added
by you.  So your business logic to register these new clients, would be
different than if a client registered from your existing website.  You
would probably want to send them a special email that says "We just
bought Company xyz and since you were registered on xyz site, we have
seamlessly integrated your account into our site, simple use your same
username and password and login here".  It's obvious that this is an
oversimplified "what-if", but you get the idea--I hope?

Also, I couldn't possibly imagine that DHH (please chime in at anytime)
would advocate NOT using controllers furthermore continue to develop
something that was deemed useless.

I think you are getting a little bogged down in theory and over
analyzing these things.  You should look at what other projects have
done.  You can download the source to typo or a host of other rails apps
to see what is common practice.


Chris
Pat M. (Guest)
on 2006-05-05 04:48
(Received via mailing list)
On 5/4/06, Chris B. <removed_email_address@domain.invalid> wrote:
> I am sure many people have different opinions about this, however in the
> strictest sense business logic belongs in the controller.  Along with
> the strictness in mind, some people would argue if validation is
> business logic or part of the data model.  But I would guess that a
> "rich domain model" means all the things needed to maintain data
> integrity and, in some cases, to make it easy to get things out of the
> data model (by using associations) should be in the model.  But in most
> cases, associations and validations are common across all business
> logic, so it makes great sense to put those in the data layer.

We're not dealing with MVC in the strictest sense though, are we?
We're dealing with it in the Rails sense.  Does that change anything?


> But a controller is indeed for business logic.  Controllers aren't only
> for web access, although they are strongly tied to it in this framework
> because it IS a web framework, they can "speak" xml, soap, xml-rpc, and
> a host of other ways to allow other applications access through your
> controller.

Okay so if I wanted to easily manage my app through the console, what
would be the best way to do this?  Do I create a web services
interface?


> seamlessly integrated your account into our site, simple use your same
> username and password and login here".  It's obvious that this is an
> oversimplified "what-if", but you get the idea--I hope?

I kind of don't...the business logic changed.  I'm going to have to
change my code around whether it's in the controller or the model.  As
you said, this is a very simplified example, and in this case it's
just a case of sending a different email, so it's not clear to me why
it'd be preferable to keep that logic in the controller.


> I think you are getting a little bogged down in theory and over
> analyzing these things.  You should look at what other projects have
> done.  You can download the source to typo or a host of other rails apps
> to see what is common practice.

Will do.  Thanks for discussing this with me.  I thought I had it
down, but apparently I'm very confused.

Pat
Conrad T. (Guest)
on 2006-05-05 05:15
(Received via mailing list)
Hey, after doing some light research on this issue, here what I was able
to
find "Head First:  Design Patterns" from page 559:

Q:  Does the controller ever implement any application logic?

A:  No, the controller implements behavior for the view.  It is the
smarts
that translates the actions from the view to actions on
      on the model.  The model takes those actions and implements the
application logic to decide what to do in response to those
      actions.  The controller might have to do a little work to
determine
what methods calls to make on the model, but that's not
      considered the "application logic".  The application logic is the
code
that manages and manipulates your data and it lives in the
      model.

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