Rails - Jul 2006 - Which is the best place to put business logic ?

Hello, I wonder if it''s better to put business logic in the controller 
or in the model (I presume model is better)

Eg. client controller, disable_account action

client = Client.find(params[:id])
client.send_pending_invoices()
client.login_enabled = false
client.receive_newsletter = false

or

client = Client.find(params[:id])
client.disable_account() # and put the whole stuff in this method ?



Which is the best one ?

Thanks

-- 
Posted via http://www.ruby-forum.com/.

On Jul 26, 2006, at 4:19 AM, nuno wrote:
> Hello, I wonder if it''s better to put business logic in the
controller
> or in the model (I presume model is better)
>
> Eg. client controller, disable_account action
>
> client = Client.find(params[:id])
> client.send_pending_invoices()
> client.login_enabled = false
> client.receive_newsletter = false
>
> or
>
> 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.

cr

>On Jul 26, 2006, at 4:19 AM, nuno wrote:
>> Hello, I wonder if it''s better to put business logic in the
controller
>> or in the model (I presume model is better)
>>
>> Eg. client controller, disable_account action
>>
>> client = Client.find(params[:id])
>> client.send_pending_invoices()
>> client.login_enabled = false
>> client.receive_newsletter = false
>>
>> or
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060803/42f8cfe5/attachment.html

On Aug 3, 2006, at 8:26 AM, Ennis, Jay wrote:
> >On Jul 26, 2006, at 4:19 AM, nuno wrote:
>
> >> Hello, I wonder if it''s better to put business logic in
the
> controller
> >> or in the model (I presume model is better)
> >>
> >> Eg. client controller, disable_account action
> >>
> >> client = Client.find(params[:id])
> >> client.send_pending_invoices()
> >> client.login_enabled = false
> >> client.receive_newsletter = false
> >>
> >> or
> >>
> >> 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?
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060803/45890d82/attachment.html

Chuck Remes 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



-- 
Posted via http://www.ruby-forum.com/.