Where put buissness logic?

Rails
1

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/)

2

Maciej P. 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!

3

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 P. [email protected] 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.

4

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.

5

On Fri, 11 May 2007 02:53:15 +0200, Daniel W. wrote:

Maciej P. 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/)

6

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 © 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

7

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.