Matthijs L. wrote:
How much business logic is actually allowed in a (Rails) controller?
In the attachement I’ve put down three different approaches to the
Which if the three approaches is preferable?
- Calling Payment.create! directly.
- Calling Payment.create! from Order#add_payment wrapper.
- 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?
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
hope this helps