Stephane E. wrote:
I think an observer (ActiveRecord::Observer) would be a good place for
complex business logic. Near the model but not clogging it up.
Sorry, but no. An observer can form part of your model and is a good
way of implementing behaviour that needs to be called when things happen
in other parts of your model without coupling the two behaviours
together tightly. This is purely an object design consideration. If your
individual model objects are getting “clogged up” then its a sign that
you need to refactor.
By its very definition, MODEL == BUSINESS LOGIC. Its called a model
because it is a model of your business domain (or at least a subset of
it which is relevant to your application). Consequently it is often
called a domain model.
Persistance doesn’t really have anything to do with business logic - its
part of the infrastructure layer. It just so happens that the
ActiveRecord pattern chooses to keep persistance and business rules
Without going into a huge debate over the pros and cons of this
(needless to say ActiveRecord works pretty well and hides a lot of the
persistance layer from you), its fair to say that the place for your
business logic is in the model, and in a Rails app, inside the
app/models folder. However, a model object does not have to just be an
ActiveRecord object - there may well be objects in your domain model
that don not need persisting…service layers, value objects etc. They
should still sit in the model directory.
Use lib for things like external libraries, non-model classes,
extensions, monkey patches, utilities etc.