Rails - Aug 2006 - Theoretical: Should models be subclasses of AR or mix it in?

All,

My apologies if this is a little long-winded and stream of 
consciousness-y :).

SUMMARY: Why do we extend ActiveRecord instead of mixing it in to our 
model classes?

Been thinking about my app''s models and starting to want to build 
something of a hierarchy.  I have some commonality across 3 of my model 
classes and I''d liek to aggregate the behavior in a superclass. 
However, I am stuck with all of my models being descendants of AR.  So 
within my set of models, I can''t aggregate common behavior into a 
superclass within that hierarchy since my DB tables (legacy) do not 
reflect that hierarchical structure.

So I''ve been thinking about why the model relationship to AR is 
extension and not composition (why do models extend AR instead of 
include/mixin it).  I can certainly agree with the idea that the essence 
of a model class _is_ that it''s an OR mapping, but if you mixed in the 
OR-mapping-ness instead of forcing it through your one shot at 
inheritance (extending AR), you would still have the freedom to have 
more non-database concerns be addressed (like a model object hierarchy 
that doesn''t map to your persistence layer).

Given the fact that model classes do extend AR, you can certainly create 
"pure model" classes that then mixin the AR subclasses or delegate to 
the AR subclasses to handle persistence and then you can have whatever 
model object heirarchy you want.  Which I guess makes sense since your 
application model shouldn''t necessarily be bound so tightly to your 
persistence layer.  Another option is to mix in your common domain 
behavior from a module ("interface").

My thought is that the model side of Rails is sort of presented as 
though you can handle everything within the constraints of being an AR 
descendant, but in fact, the AR descendants are just a persistence 
object layer.

It just feels like the persistence piece should be what is mixed in, not 
the domain behavior.

Any thoughts?

Wes


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

If you mixed in AR instead of subclassing it, would the whole 
method_missing scheme work?

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

On one of my projects I actually had a "base" active record model and 
subclassed it for other models - would that work for you?

On Tuesday 15 August 2006 06:39, Wes Gamble wrote:
> All,
>
> My apologies if this is a little long-winded and stream of
> consciousness-y :).
>
> SUMMARY: Why do we extend ActiveRecord instead of mixing it in to our
> model classes?
>
> Been thinking about my app''s models and starting to want to build
> something of a hierarchy.  I have some commonality across 3 of my model
> classes and I''d liek to aggregate the behavior in a superclass.
> However, I am stuck with all of my models being descendants of AR.  So
> within my set of models, I can''t aggregate common behavior into a
> superclass within that hierarchy since my DB tables (legacy) do not
> reflect that hierarchical structure.
>
> So I''ve been thinking about why the model relationship to AR is
> extension and not composition (why do models extend AR instead of
> include/mixin it).  I can certainly agree with the idea that the essence
> of a model class _is_ that it''s an OR mapping, but if you mixed in
the
> OR-mapping-ness instead of forcing it through your one shot at
> inheritance (extending AR), you would still have the freedom to have
> more non-database concerns be addressed (like a model object hierarchy
> that doesn''t map to your persistence layer).
>
> Given the fact that model classes do extend AR, you can certainly create
> "pure model" classes that then mixin the AR subclasses or
delegate to
> the AR subclasses to handle persistence and then you can have whatever
> model object heirarchy you want.  Which I guess makes sense since your
> application model shouldn''t necessarily be bound so tightly to
your
> persistence layer.  Another option is to mix in your common domain
> behavior from a module ("interface").
>
> My thought is that the model side of Rails is sort of presented as
> though you can handle everything within the constraints of being an AR
> descendant, but in fact, the AR descendants are just a persistence
> object layer.
>
> It just feels like the persistence piece should be what is mixed in, not
> the domain behavior.
>
> Any thoughts?
>
> Wes

No I''ve had to do that as well.

I''m talking about several model objects that all share certain 
attributes, and for whatever reason, are persisted to different tables.

So, maybe model1, model2, model3 share attr1, attr2 but they each have 5 
other attrs that differ.

One way to go is to take advantage of AR to impose a pseudo-object model 
onto your DB schema and store the 2 common attrs in one table and then 
have 3 separate tables to store the 5 differing attributes.  This would 
lend itself to a "base" object that maps to the "common"
table and 3
concrete AR objects that each map to a specific table.

But, many times, you either can''t (legacy) schema, or don''t
want to get
into the business of representing your object model so directly in the 
schema.  You don''t mind the overhead of storing the same types of 
attributes in three different tables because keeping the entities in one 
place is more important than the "object purity" of the relational 
schema.

There is an ability to declare the superclass of a set of classes as 
"abstract" which implies that it doesn''t have a persistent
table behind
it, but I don''t think that you can put any code which you would expect 
to interact with a table to read or write in that class.

Here''s a specific example.  My app. stores filesystem artifacts, like 
images, HTML docs, and stylesheets.  All of these objects share a 
filesystem path.  They are curently efined as separate model objects. 
I''d like to centralize the path accessor methods to make things DRYer. 
And this is how I came to write the post.

Wes

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

As an alternative to changing how models use AR, you could create a module
with the shared methods and mix that into each of your models

mark

On 8/15/06, Wes Gamble <weyus@att.net> wrote:
>
> No I''ve had to do that as well.
>
> I''m talking about several model objects that all share certain
> attributes, and for whatever reason, are persisted to different tables.
>
> So, maybe model1, model2, model3 share attr1, attr2 but they each have 5
> other attrs that differ.
>
> One way to go is to take advantage of AR to impose a pseudo-object model
> onto your DB schema and store the 2 common attrs in one table and then
> have 3 separate tables to store the 5 differing attributes.  This would
> lend itself to a "base" object that maps to the
"common" table and 3
> concrete AR objects that each map to a specific table.
>
> But, many times, you either can''t (legacy) schema, or
don''t want to get
> into the business of representing your object model so directly in the
> schema.  You don''t mind the overhead of storing the same types of
> attributes in three different tables because keeping the entities in one
> place is more important than the "object purity" of the
relational
> schema.
>
> There is an ability to declare the superclass of a set of classes as
> "abstract" which implies that it doesn''t have a
persistent table behind
> it, but I don''t think that you can put any code which you would
expect
> to interact with a table to read or write in that class.
>
> Here''s a specific example.  My app. stores filesystem artifacts,
like
> images, HTML docs, and stylesheets.  All of these objects share a
> filesystem path.  They are curently efined as separate model objects.
> I''d like to centralize the path accessor methods to make things
DRYer.
> And this is how I came to write the post.
>
> Wes
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
Mark Van Holstyn
mvette13@gmail.com
http://lotswholetime.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/d86753e4/attachment-0001.html

Yup, absolutely.

Recognizing that you can go either way, I''m questioning why the AR 
functionality isn''t mixed in since it''s more operational in
nature (AR
"enables" a model to be easily backed in a relational store).

Make sense?

Wes

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

On 8/15/06, Wes Gamble <weyus@att.net> wrote:
> All,
>
> My apologies if this is a little long-winded and stream of
> consciousness-y :).
>
> SUMMARY: Why do we extend ActiveRecord instead of mixing it in to our
> model classes?
>
<snip stream-of-consciousness>

I have an ModelHelper module in /lib which reopens AR::Base and holds
methods I want to share across all models. I just need to be careful I
don''t overwrite any critical AR::Base functionality, of course.

jh


-- 
James Hughes
Web application developer
Vancouver, BC

"Developing a coherent political analysis is in many respects
contingent upon an ability to connect one context to another, a
process not dissimilar to playing the kid''s game of dot-to-dot."
 - Ward Churchill, from ''"A Government of Laws"?''