MVC design question

Rails
1

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?

2

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

3

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

4

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.