Business logic in controller?

I've been striving to learn proper Rails practices and have an
"opinionated" question. I've seen stated in many places that the
business logic belongs primarily in the model. How important is that?

I have a case in which I am tracking employee days off. My view will
allow the user to enter the beginning and end date of their vacation,
but I need to store the date of each day off separately. Further, I
need to remove weekends and holidays.

I have a good idea of how to do this in the controller by iterating
through the dates and saving those that qualify. (I could populate a
collection and do the save in one step, I suppose, but I'm not sure
what the advantage would be.)

So, is it okay, by Rails standards, to put this type of logic in the
controller?

Thanks.

The code that iterates through the dates and creates the needed
records is better in a model instead of a controller.

The controller and view can gather the starting and ending dates, but
then pass them to the model to do any business logic.

Think about what would happen if you added a new type of interface to
gather the date information - say a special version for mobile phone
browsers. Or something that runs as part of a cron job that extracts
the information from an external database. These can share the same
model, and so your business logic is only in one place - the model.
(This follows the DRY principle - Don't Repeat Yourelf.) The business
logic does not depend on how the dates are gathered, so it should not
reside in a controller or view.

Hope that helps.

Yes, it does. Thank you.

billv wrote:

I've been striving to learn proper Rails practices and have an
"opinionated" question. I've seen stated in many places that the
business logic belongs primarily in the model. How important is that?

Easy: Anything your user can do to your model, thru the View...

...a unit test can do to your Model, without the Controller's help

The controller should be considered just a dab of glue between View and Model.

I have a case in which I am tracking employee days off. My view will
allow the user to enter the beginning and end date of their vacation,
but I need to store the date of each day off separately. Further, I
need to remove weekends and holidays.

I have a good idea of how to do this in the controller by iterating
through the dates and saving those that qualify. (I could populate a
collection and do the save in one step, I suppose, but I'm not sure
what the advantage would be.)

Refactor that logic into the Model and leave it there. Tests should then show you can pass dates into the Model, and it processes them appropriately.

So, is it okay, by Rails standards, to put this type of logic in the
controller?

A bunch of code in your controller that is doing business logic is
usually because:

a) you're lazy (like me), or
b) you like to code first, then refactor (again, like me)

Most of the time, that code can delegated to the model instead.

If it *really* doesn't feel right for your current model, that's usually
a hint that there's another model hiding in the code that you haven't
realized yet.