Forum: Ruby on Rails Java/J2EE DAO/model objects vs. Ruby/Rails model objects

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
6661ef9d747db3af8896cd94959d717d?d=identicon&s=25 Paul Barry (Guest)
on 2006-04-13 21:23
(Received via mailing list)
In typical Java/J2EE applications, domain model object do not have much
logic, they are basically data holders.  It seems to be considered a sin
put persistence logic in the domain model objects, instead it should be
a DAO (Data Access Object).  I have always thought this seems funny,
all, what seems more natural/object-oreiented?:


In Ruby/Rails, the model objects implement persistence themselves, by
extending ActiveRecord::Base.  So it seems as if the Ruby/Rails way is
opposite of the Java/J2EE DAO pattern.  In your opinion, is the DAO
fundamentally flawed?  Or is Ruby/Rails only meant for simple/small
applications, so the DAO pattern is overkill.  Are there cases where the
pattern should be used?
5ac4033486edab2e9059ca1ccf13c8fa?d=identicon&s=25 Jordan McKible (jmckible)
on 2006-04-13 21:56
Paul Barry wrote:
> or

I find the DAO pattern to be painful to implement.  Writing miles of XML
configuration aside (this is especially painful in Hibernate), it makes
a lot more logical sense to be able to call

In frameworks like Spring, only the service layer has access to the DAOs
and therefore could only be called from there.  While
this is all well and good if you are following the framework, I've run
into numerous problems when trying to share DAOs and service layers
between projects.

The power the DAO pattern really gives you is the ability to implement
accessing your data in different methods.  For example, either with JDBC
or with Hibernate.  But who really needs this?  Once you decide you are
going with JDBC or Hibernate for your project, implementing the DAO
layer just takes an annoying amount of time to configure.
6661ef9d747db3af8896cd94959d717d?d=identicon&s=25 Paul Barry (Guest)
on 2006-04-13 22:06
(Received via mailing list)
I think the DAO pattern was born in the JDBC only days, where the idea
that your JDBC code would probably be dtabase-vendor specific, so you
have an OracleDaoImpl and MySqlDaoImpl, but you're right, hibernate kind
takes care of that for you, so a HibernateDaoImpl, kind of covers
everything.  But still, how would you even implement a no service/no DAO
object in Java?

Maybe using Spring you could have a User object that has a UserDao
which is set to a concrete implementation by spring.  Then your user
could have a save method that calls  Not sure how
could do the class method like find though.

But I agree though, the Ruby/Rails way of having the domain object
itself, persist itself, etc., seems more natural, but there's nothing
special about Ruby/Rails that makes that work.  It can be done in
and I'm just wondering if there is a reason why it hasn't been done that
B3260ee62969961010117e21e9872a3a?d=identicon&s=25 Kenneth Lee (Guest)
on 2006-04-18 17:42
(Received via mailing list)
I believe it has been done in Java by someone, using dynamic proxies
or using bytecode engineering.  But I think it's more a resistance by
the Java community to have a lot of "magic" happening in their code.
So the norm has been to stick with those frameworks where things have
to happen explicitly.  Contrast that to Ruby where it's trivially easy
to instrument an existing object w/ a new method.
This topic is locked and can not be replied to.