Forum: Ruby on Rails Where put buissness logic?

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.
1e8f141e7857d397d8020ed3b759e88a?d=identicon&s=25 Maciej Piechotka (Guest)
on 2007-05-11 02:00
(Received via mailing list)
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/)
42292bf8a0acbc98862d9306b501275d?d=identicon&s=25 Daniel Waite (rabbitcreative)
on 2007-05-11 02:53
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!
7529d5f2a3abf50f74573a5e99a1b18b?d=identicon&s=25 Anthony Gardner (Guest)
on 2007-05-11 09:50
(Received via mailing list)
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@gmail.com> 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.
1e8f141e7857d397d8020ed3b759e88a?d=identicon&s=25 Maciej Piechotka (Guest)
on 2007-05-12 00:11
(Received via mailing list)
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/)
21f7ed21f11a809050594c82eab11d67?d=identicon&s=25 Robert Walker (Guest)
on 2007-05-12 00:44
(Received via mailing list)
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.
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2007-05-22 13:19
(Received via mailing list)
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
24b05e200310d4673bf93e9349067887?d=identicon&s=25 Paul Sturgess (Guest)
on 2007-05-22 18:59
(Received via mailing list)
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
This topic is locked and can not be replied to.