How much business logic is actually allowed in a (Rails) controller? In the attachement I've put down three different approaches to the same problem. Which if the three approaches is preferable? 1) Calling Payment.create! directly. 2) Calling Payment.create! from Order#add_payment wrapper. 3) Calling Payment.create! from Order#add_payment wrapper without checking Order#payable from controller. Am I violating any design patters with the last, and is it wise to wrap around the Payment.create instance method in Order#add_payment?
on 2007-05-04 11:00
on 2007-05-04 15:50
Since this is a philosophical question you are bound to get many different answers, no one answer will be "it" or correct for all situations. Item 1 is clear to the reader what is happening but requires the controller to know about how the models relate to each other. Item 2 has the advantage that how order and payment are related is not known by the controller, just that they are related. I think that the add_payment method should do any checking since its value is to hide the implementation of the connection between the two classes from the controller. If the controller knows what relation to test it serves no purpose to hide that in the add_payment method. Michael On May 4, 2:00 am, "Matthijs Langenberg" <mlangenb...@gmail.com>
on 2007-05-04 15:53
Matthijs Langenberg wrote: > How much business logic is actually allowed in a (Rails) controller? > In the attachement I've put down three different approaches to the > same problem. > Which if the three approaches is preferable? > > 1) Calling Payment.create! directly. > 2) Calling Payment.create! from Order#add_payment wrapper. > 3) Calling Payment.create! from Order#add_payment wrapper without > checking Order#payable from controller. > > Am I violating any design patters with the last, and is it wise to > wrap around the Payment.create instance method in Order#add_payment? Matthijs, While it's advised to keep away from putting business logic in your controllers, it's meant more as a guideline than a hard fast rule. Secondly, you can not "violate" a design pattern as they themselves are well established guidelines that sometimes have to be modified to meet your specific problem domain. Your methods out of context provide little to no clue as to whether they belong in the controller or not.. Don't worry too much about it and while you are writing your app, just think to yourself, if the code that you are writing has to to with manipulating your model it's probably belongs in the model (bussiness layer) and if it pertains to organizing models to feed to your views, it probably belongs in the controller.. The difference between question 2 and 3 has nothing to do with design patterns. It pertains specifically to the requirements of your problem domain. hope this helps ilan
on 2007-05-04 20:29
Thanks for these very helpful replies, I've chosen to call Order#add_payment directly from the PaymentController without any conditions, besides checking the parameters, which is a controller thing. Order#add_payment calls Payment.create! on certain conditions. And raises an exception if those conditions aren't met e.g. Order#payable? returns false. Since there are several conditions on which Payment.create! should not be called, Order#add_payment raises specific exceptions for each of those conditions, this way I can provide error messages to the users without having a bunch of conditions in PaymentController#create which /must/ be called in order to keep the business logic alive.