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
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
Thanks. I heard many contradictive things about MVC.
Regards
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.
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
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.
