On Jul 26, 2006, at 4:19 AM, nuno wrote:
Hello, I wonder if it’s better to put business logic in the
controller
client = Client.find(params[:id])
client.disable_account() # and put the whole stuff in this method ?
Your second choice is correct. The controller merely glues the model
to the view. Changing the internal state of the model should be done
purely by methods on that object.
I think this example is the trivial case since quite often the business
logic spans many models. Certainly encapsulate any and all business
logic that is model-specific into that model, but do you really want to
have one model making use of another to accomplish the business logic?
I think that you have no choice but to put the rest in the controller.
Am I missing something?
je
On Aug 3, 2006, at 8:26 AM, Ennis, Jay wrote:
client.login_enabled = false
I think this example is the trivial case since quite often the
business
logic spans many models. Certainly encapsulate any and all business
logic that is model-specific into that model, but do you really
want to
have one model making use of another to accomplish the business logic?
I think that you have no choice but to put the rest in the controller.
Am I missing something?
I think you might be. There is no rule or convention that disallows
one model from using the services of another. You can see this in
action by looking at the “depot” example in the Agile WebDevw/Rails
book when the Order model uses the LineItems model. The relationships
between models (has_one, has_many, etc) imply this kind of business
logic dependency anyway.
cr
Chuck R. wrote:
On Aug 3, 2006, at 8:26 AM, Ennis, Jay wrote:
client.login_enabled = false
I think this example is the trivial case since quite often the
business
logic spans many models. Certainly encapsulate any and all business
logic that is model-specific into that model, but do you really
want to
have one model making use of another to accomplish the business logic?
I think that you have no choice but to put the rest in the controller.
Am I missing something?
I think you might be. There is no rule or convention that disallows
one model from using the services of another. You can see this in
action by looking at the “depot” example in the Agile WebDevw/Rails
book when the Order model uses the LineItems model. The relationships
between models (has_one, has_many, etc) imply this kind of business
logic dependency anyway.
cr
In addition, there is no problem with creating models that encapsulate
business logic, but are not tied to a particular database table (iow, a
non-ActiveRecord model). The cart object in the AWDWR tutorial is an
example. In that case, the business logic does not clearly belong to one
of the db based models, but it also should not be in the controller.
Keith