Question

So Im trying to teach myself rails and having some trouble with figuring out where logic goes.
In my exercise, I have a payment model.
class pyament
Integer Product_Type
String Product_name

There are rules for handling payments
if the product_Type is physical, do this, if virtual do that
if the product_name is book, do this
if the product_name is cow, do that

What I cant figure out is where to put these rules.
Do I make a method in the model called process that runs these rules? Does this go logic go in the controller? Im just not clear on this.

Any insight would be appreciated.

Thanks

Answer 1

You should definitely keep this logic in the model, and in fact, if the logic is significantly different between different types you should use multiple models with Single Table Inheritance.

See:
http://joemcglynn.wordpress.com/2009/12/11/rails-sti-part-1/
http://joemcglynn.wordpress.com/2009/12/12/rails-single-table-inheritance-part-2/

Basically the idea is this: You’re already defining Product Type — the ‘type’ column is the main feature of an STI table.

With STI instead of having one model with tons and tons of conditional logic or multiple models, you have several VERY SIMILAR models with VERY SIMILAR data but somewhat different logic, so all those related models can share the same table, and inherit from a common class.

For instance:

class Product < ActiveRecord::Base
  ...
  common logic goes here
  ...
end

class PhysicalProduct < Product
  ...
  physical-product-specific logic goes here
  ...
end

class VirtualProduct < Product
  ...
  virtual-product-specific logic goes here
  ...
end

So, in this way you can create a method like product.deliver which is defined by default in the product model to trigger shipping a product — but in the VirtualProduct model is overridden to trigger emailing a download link instead.

ActiveRecord handles all of this very nicely (see the linked articles above for a walkthrough), and the majority of your forms and links and controllers etc. will continue to work the same way they currently do.

In general you always want to keep as much logic as possible in the models instead of the controllers, because models are easier to test, and easier to debug. In your situation STI is a nice way to keep this branching logic in the models an out of the controllers and views.