Where should "business logic" reside in Rails?

Hi all,

What is the preferred location for my Business Logic? I have complex
business rules that go across a specific data model.

Are model classes primarily for record I/O and validations? Would
business logic classes also reside in ./app/models? Or would these
classes reside in the ./lib directory? (If not, what type of code goes
in ./lib?)

I am thinking about the differentiation of the EJB Session and Entity
Beans … or perhaps the paradigm is simplified in Rails?

Thanks in advance for the enlightenment!

Allen

I think Model should also keep the business logic part.

IMHO, and according more or less to the MVC theory, Model stores the
business logic of the application and the persistent data. The business
logic could not be attached closely to the persistent data, but it is
information about your application that perhaps should be kept in there.

Allen F. wrote:

Hi all,

What is the preferred location for my Business Logic? I have complex
business rules that go across a specific data model.

Are model classes primarily for record I/O and validations? Would
business logic classes also reside in ./app/models? Or would these
classes reside in the ./lib directory? (If not, what type of code goes
in ./lib?)

I am thinking about the differentiation of the EJB Session and Entity
Beans … or perhaps the paradigm is simplified in Rails?

Thanks in advance for the enlightenment!

Allen

In the Pragmatic Programmers Rails course, there’s a slide that says
each part of MVC is a different part of a company.

M = administration
V = marketing
C = CEO/executive

I don’t know if that’s perfect, but it’s pretty good.

Bill

M = administration
V = marketing
C = CEO/executive

Well if you think of the roles of a company and the roles of each
component in software architecture, they don’t really match up. Maybe
it’s better to say the Model is the CEO/executive, since he has all the
business knowledge, and the Controller is the Administration since they
do the bookkeeping work to make sure everything works. We’ll keep the
view with the marketing, that makes sense :stuck_out_tongue:

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
closely coupled.

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.

Don’t be sorry Luke, excellent comment. I especially like this
sentence:

However, a model object does not have to just be an
ActiveRecord object

It made my mind much clearer.
Thanks.

I think an observer (ActiveRecord::Observer) would be a good place for
complex business logic. Near the model but not clogging it up.

On Monday 14 August 2006 18:18, Luke R. wrote:

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.

I agree completely as it fits in well with good, ordinary
object-oriented design anyway. That said, with Rails it is, on the one
hand, often sinfully easy to put business logic in the controller and,
on the other hand, not obvious how to properly put it into a model
object.

For a start, how do you handle transactional(!)
creation/update/destruction of multiple interrelated objects? Most code
I’ve seen just stuffs parts of the params hash into various
constructors and update_attributes methods in controller code. And
stuff like this barely touches on business logic.

Michael


Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs