Michael G. wrote:
On Jan 19, 2006, at 2:19 , Ben M. wrote:
I see a lot of discussion of the limitations of ActiveRecord on
thislist. Well, there’s nothing saying that you can’t create your model
classes as the domain dictates and have them use the ActiveRecord
objects as (extremely) convenient DAOs.That sounds interesting. Could you expand on that, or perhaps provide
references to where I might find more information on this?
No, sorry I can’t… cuz I was just theorizing. I don’t know if anyone’s
actually done
this. It would probably be an uphill effort because rails does so much
for you as long as
you “stick to the script”.
I would think that rather than the usual DAO approach, in which the DAOs
query the
database and return an assembled model object, the ActiveRecord might be
good as just a
member variable of the model. You could have a model base class that has
the ActiveRecord
var and the basic delegate methods. The actual instance of ActiveRecord
would be set in
the subclass model object.
Or, you could have a helper, basically a DAO, that creates an
ActiveRecord instance for a
specified table and handles db calls on behalf of the corresponding
model class. This
could be arranged using the “aggregates” approach Eric Evans advocates
in the book Domain
Driven Design. Well, that pattern is intended to control the chaos of
too many classes
talking to too many other classes in a large system. But the “root” of
the “aggregate”
could also be respsonsible in our system for maintaining ActiveRecord
objects for all of
its child objects.
Now, I’m just blundering around here, theorizing off the cuff… so
please take this as
such. Like I said above, the problem with all this is that rails is
based on a merged
domain and data access layer; its one fatal flaw if you ask me… but it
does make small
apps very easy to kick out.
I suspect that someone will want separation of concerns bad enough that
they’ll write a
plugin or module to facilitate using “POROs” (plain old ruby objects)
for the model with
mixins to use whatever data access library you want.
A good first step towards this would be to separate Validations out of
ActiveRecord,
allowing it to be mixed in to model classes. And ActiveRecord should be
a mixin in too. My
model classes don’t have an “is-a” relationship with ActiveRecord.
That’s because
persistence is an orthogonal concern and it should be treated as such!
I’m surprised that
someone like Martin F. hasn’t taken DHH over his knee and spanked
him for this yet.
Ahem. Anyway, once again… these are the ravings of someone who’s read
about three
quarters of the agile book and played with a few examples. Flames
welcome. 
b
