Learning Basic rails: Where to put conditional business logic?

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

---

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.

---

For starters, this list is a nice jumping off point.

I agree that the data manipulation / business rules best fit in the model. Keep the views and controllers clean so your model can contain all the storage structures and logical rules.

---

Generally you want your business logic in the models. "Fat Model, Skinny Controller" is the cool Rails phrase used to describe this. See this post for more info, and don't pay attention to the out-dated Rails syntax.