Hi,
Given the convention of fat models to handle business logic, is there a point where you might be justified in using a separate plain ruby object(s) to orchestrate certain business logic interactions, essentially a middle layer between your controllers and models for high level functions?
If you look at the InventoryTransaction model below you will see the sort of methods I mean. In this case they are similar to factory methods I suppose. However, I could end up with around 30+ different method handling different kinds of inventory adjustments.
Most of these methods are non-trivial as the lookup and create other models and then interact with them in achieving the desired business function.
What are peoples experience with this? Leave them in the single model or extract them to plain ruby classes (possibly within the models folder) with a bunch of class methods to handle high level business logic? This would also allow grouping methods of related functionality in to separate classes.
Am I heading for future issues?
class InventoryTransaction < AR::Base
has_many :inventory_account_entries validate :inventory_account_entries_balance
def manually_add_inventory(product, location, quantity) ...create new transaction and suitable entries in to inventory accounts end
def manually_remove_inventory(product, location, quantity) ...create new transaction and suitable entries in to inventory accounts end
def report_shortage(product, location, quantity) ...create new transaction and suitable entries in to inventory accounts end
def report_surplus(product, location, quantity) ...create new transaction and suitable entries in to inventory accounts end
... plus many more potential inventory interactions or events resulting in movement between inventory accounts and the creation of a new InventoryTransaction record end
Thanks, Andrew.