Rails - Aug 2006 - 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

-- 
Posted via http://www.ruby-forum.com/.

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 Fair 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

-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

> 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 :P

-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

Stephane Elie 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.

-- 
Posted via http://www.ruby-forum.com/.

On Monday 14 August 2006 18:18, Luke Redpath 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 Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

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.

-- 
Posted via http://www.ruby-forum.com/.