Rails - May 2007 - Where put buissness logic?

I''ve always think that it belongs to controller but I''ve read
few
articles that it should be done by model and controller should be thin 
glue betwean model and view. Where should I put it?

Regards
-- 
I''ve probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Maciej Piechotka wrote:
> I''ve always think that it belongs to controller but I''ve
read few
> articles that it should be done by model and controller should be thin
> glue betwean model and view. Where should I put it?
Thick models, thin controllers and dumb views. That''s the general idea 
with Rails (or any MVC architecture).

There''s been plenty of discussion on this board and other web sites in 
the past. Look around; I''m sure you''ll find some useful stuff.

A good rule of thumb is this: your application should be completely 
usable from console, without any controllers or views.

Hope that helps!


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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Well, we''ve been having a big discussion on this subject on
Perl''s Catalyst mailinglist and it seems to be common consesus that
your business logic is outside of the web application and that the model is a
thin wrpaper around that.

It depends on what your doing, as well.

So, there are lots of factors but, try to keep you business logic out of the
controller as it should be pretty dumb (in my opinion)

-Ants


Maciej Piechotka <uzytkownik2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
I''ve always think that it belongs to controller but I''ve read
few
articles that it should be done by model and controller should be thin 
glue betwean model and view. Where should I put it?

Regards
-- 
I''ve probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)






 		
---------------------------------
 Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, 11 May 2007 02:53:15 +0200, Daniel Waite wrote:
> Maciej Piechotka wrote:
>> I''ve always think that it belongs to controller but
I''ve read few
>> articles that it should be done by model and controller should be thin
>> glue betwean model and view. Where should I put it?
> 
> Thick models, thin controllers and dumb views. That''s the general
idea
> with Rails (or any MVC architecture).
Thanks. I heard many contradictive things about MVC.

Regards
-- 
I''ve probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The conflicting information is due to the many ways that MVC is being
misused.  MVC is a pattern, patterns are guidelines and are often
interpreted in many different ways.  MVC is not a complete pattern.
There are many other patterns that can be appended to the MVC, such as
delegate patterns, observer patterns, etc.

Here is my opinion on the subject:  Every piece of logic has it''s
place.  The job of the developer is to "discover" where that place
is.  If it''s not initially clear where it belongs, then it''s
likely
that you don''t yet completely understand the problem domain.

So you ask yourself these simple questions:

1. Does this logic manipulate the data in anyway?
2. Does this logic support translating (but not modifying) the data
and communicate that data to some form of presentation?
3. Is this logic purely manipulating how the data is presented?
4. Is this support logic that doesn''t fit anywhere in the above
questions, or is it useful to all three.

If 1 you have model logic.
if 2 you have controller logic.
if 3 you have view logic.
if 4 then you have either helper, or library logic.

If you can answer yes to more that one of these questions then you
have discovered where the logic need to be separated.

On May 11, 5:48 pm, Maciej Piechotka
<uzytkown...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Fri, 11 May 2007 02:53:15 +0200, Daniel Waite wrote:
> > Maciej Piechotka wrote:
> >> I''ve always think that it belongs to controller but
I''ve read few
> >> articles that it should be done by model and controller should be
thin
> >> glue betwean model and view. Where should I put it?
>
> > Thick models, thin controllers and dumb views. That''s the
general idea
> > with Rails (or any MVC architecture).
>
> Thanks. I heard many contradictive things about MVC.
>
> Regards
> --
> I''ve probably left my head... somewhere. Please wait untill I find
it.
> Homepage (pl_PL):http://uzytkownik.jogger.pl/
> (GNU/)Linux User: #425935 (seehttp://counter.li.org/)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''ve been just pondering this item and have seen conflicting info in
the
"Agile Development with Rails" book, probably due to the manner in
which
"business logic" is overloaded.

Robert - I liked your summation.

What do people think about the case:  I have a high level "save" that
incorporates saving the parent and child data.  The per field validations
are already covered by the rails framework, however what about business
logic cross checks I need to do with the data, e.g. there can only be one
row with a given "event_type" for each "trans_id", or
another way: records
which have transaction id X can have only one entry for which
"event_type" Y.  So:

(a) Could I assume this is a higher level business logic validation check,
and incorporate this in the model (makes most sense to me short of creating
another layer)

(b) Given that it is in the model what approach would be best to pass this
back to the controller layer:  (a) exceptions, (b) use of rails validation
framework, or (c) custom business logic validation framework?   It
won''t be
a validation error that can align with a view field, but then again
it''s not
an exception in the sense of a system error either.  Kind of a business
logic validation alert.

Thanks
Greg


On 5/12/07, Robert Walker
<rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> The conflicting information is due to the many ways that MVC is being
> misused.  MVC is a pattern, patterns are guidelines and are often
> interpreted in many different ways.  MVC is not a complete pattern.
> There are many other patterns that can be appended to the MVC, such as
> delegate patterns, observer patterns, etc.
>
> Here is my opinion on the subject:  Every piece of logic has it''s
> place.  The job of the developer is to "discover" where that
place
> is.  If it''s not initially clear where it belongs, then
it''s likely
> that you don''t yet completely understand the problem domain.
>
> So you ask yourself these simple questions:
>
> 1. Does this logic manipulate the data in anyway?
> 2. Does this logic support translating (but not modifying) the data
> and communicate that data to some form of presentation?
> 3. Is this logic purely manipulating how the data is presented?
> 4. Is this support logic that doesn''t fit anywhere in the above
> questions, or is it useful to all three.
>
> If 1 you have model logic.
> if 2 you have controller logic.
> if 3 you have view logic.
> if 4 then you have either helper, or library logic.
>
> If you can answer yes to more that one of these questions then you
> have discovered where the logic need to be separated.
>
> On May 11, 5:48 pm, Maciej Piechotka
<uzytkown...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, 11 May 2007 02:53:15 +0200, Daniel Waite wrote:
> > > Maciej Piechotka wrote:
> > >> I''ve always think that it belongs to controller but
I''ve read few
> > >> articles that it should be done by model and controller
should be
> thin
> > >> glue betwean model and view. Where should I put it?
> >
> > > Thick models, thin controllers and dumb views. That''s
the general idea
> > > with Rails (or any MVC architecture).
> >
> > Thanks. I heard many contradictive things about MVC.
> >
> > Regards
> > --
> > I''ve probably left my head... somewhere. Please wait untill I
find it.
> > Homepage (pl_PL):http://uzytkownik.jogger.pl/
> > (GNU/)Linux User: #425935 (seehttp://counter.li.org/)
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Your case definitely sounds like model logic.

To me I always think something belongs in the model if you want the
rule to always apply, regardless of the controller or action in a
controller.

So in your case where there can only be one row with a given
"event_type", then this needs to be enforced every time the data is
manipulated, it is not controller specific.

Regarding how you might pass this back to the controller... sounds
like some custom validation could do the trick, it depends when you
need the user to be notified really.

Hope that helps clarify things,
Paul.

http://paulsturgess.co.uk

On 5/22/07, Greg Hauptmann
<greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> What do people think about the case:  I have a high level "save"
that
> incorporates saving the parent and child data.  The per field validations
> are already covered by the rails framework, however what about business
> logic cross checks I need to do with the data, e.g. there can only be one
> row with a given "event_type" for each "trans_id", or
another way: records
> which have transaction id X can have only one entry for which
"event_type" > Y.  So:
>
>  (a) Could I assume this is a higher level business logic validation check,
> and incorporate this in the model (makes most sense to me short of creating
> another layer)
>
>  (b) Given that it is in the model what approach would be best to pass this
> back to the controller layer:  (a) exceptions, (b) use of rails validation
> framework, or (c) custom business logic validation framework?   It
won''t be
> a validation error that can align with a view field, but then again
it''s not
> an exception in the sense of a system error either.  Kind of a business
> logic validation alert.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---