addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartfacebookfolderfullheartglobegmailgoogleimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Ruby Design Dicussion

From: Neil H.
Sent on: Sunday, December 18, 2011 8:54 PM
I'm having a design issue on an app I'm working on.  The app is basically a warranty/maintenance tracking system for products.  It's a Rails 3.1 app.  Since it's still in development (early) I'm keeping up with the latest and greatest.

The main piece of content for the app is a product.  There are different product types.  Each product type has several features:
  • Shared Fields/Validations/Rules
  • Individual Fields/Forms
  • Individual Validation

I've gone through a few different scenarios and here is what I have so far.  Thanks for any help, suggestions you might have.

STI - Single Table Inheritance.

It appears as if this method uses the most Rails out of the box.  The base Product Model has the main validation while the child models can have their own validations.  I'm using a single controller, I fell that the controller shouldn't really care what type of product it is working with.  All logic is either in the Model, Observer or something else yet to be seen.  The controller is in charge of finding the correct Model.  Currently I'm doing this based upon a parameter with this helper method.

  def product_model(product_type)
    klass = "#{product_type}Model".constantize

The class just call product_model param[:type] and it has the object.  In early testing this works well.  I'm able to use presenters based upon the model name.  I'm using the methodology form Ryan Bates

Basically, I pass the model object to the base presenter and it loads up the correct presenter.  I create haml files for the different product types and it loads up those forms.

From a database perspective, I can use Mongo or Mysql/Postgress.   I'm hoping to stick with Active Record just to due to my experience.  I've used Mongoid for an app before so if using a document store is a better idea, I'd be ok using it.

The rest of the app is focused around the product.  Including maintenance schedules, warranties, reminders, etc.  I do have plans of integrating with other systems from manufactures to get recommended maintenance schedules and warranties.  I was looking at the product types to be the focal points of the integrations.  Though that is yet to be seen, most likely most of these integrations will be pretty custom.


This option is a more custom approach.  It uses much less Rails out of the box.  In fact, it probably doesn't even have to be Rails.  I was thinking of a domain approach.  Where each product type can be defined in a class, then include a product module for shared functionality.  This would be a single Model with the types based upon the type field.  The product type domain class would be called form the controller,views rather then the model.  The Product Type Domain class would still include the Product for direct table access.  I would still use presenters for the view level.

Since the table structure is in defined in the product type, a schema less db makes the most sense here.

If this is a little to complicated for email, then I'd be happy to meet up somewhere to discuss.  Currently I'm leaning toward STI, but I do really like making something from scratch (it satisfies my control issues).

Neil Hastings


Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy