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.
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.
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.