Rails - Apr 2006 - Java/J2EE DAO/model objects vs. Ruby/Rails model objects

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 to
put persistence logic in the domain model objects, instead it should be put
a DAO (Data Access Object).  I have always thought this seems funny, after
all, what seems more natural/object-oreiented?:

user.save()

or

userDao.save(user)

In Ruby/Rails, the model objects implement persistence themselves, by
extending ActiveRecord::Base.  So it seems as if the Ruby/Rails way is the
opposite of the Java/J2EE DAO pattern.  In your opinion, is the DAO pattern
fundamentally flawed?  Or is Ruby/Rails only meant for simple/small
applications, so the DAO pattern is overkill.  Are there cases where the DAO
pattern should be used?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060413/49404419/attachment.html

Paul Barry wrote:
> user.save()
> 
> or
> 
> userDao.save(user)
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 user.save().

In frameworks like Spring, only the service layer has access to the DAOs 
and therefore userDao.save(user) 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.


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

I think the DAO pattern was born in the JDBC only days, where the idea was
that your JDBC code would probably be dtabase-vendor specific, so you could
have an OracleDaoImpl and MySqlDaoImpl, but you''re right, hibernate
kind of
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 property,
which is set to a concrete implementation by spring.  Then your user object
could have a save method that calls UserDao.save(this).  Not sure how you
could do the class method like find though.

But I agree though, the Ruby/Rails way of having the domain object populate
itself, persist itself, etc., seems more natural, but there''s nothing
special about Ruby/Rails that makes that work.  It can be done in Java/J2EE,
and I''m just wondering if there is a reason why it hasn''t been
done that
way.


On 4/13/06, Jordan McKible <jmckible@gmail.com>
wrote:
>
> Paul Barry wrote:
> > user.save()
> >
> > or
> >
> > userDao.save(user)
>
> 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 user.save().
>
> In frameworks like Spring, only the service layer has access to the DAOs
> and therefore userDao.save(user) 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.
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060413/95b458af/attachment.html

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.

On 4/13/06, Paul Barry <mail@paulbarry.com> wrote:
> I think the DAO pattern was born in the JDBC only days, where the idea was
> that your JDBC code would probably be dtabase-vendor specific, so you could
> have an OracleDaoImpl and MySqlDaoImpl, but you''re right,
hibernate kind of
> 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
property,
> which is set to a concrete implementation by spring.  Then your user object
> could have a save method that calls UserDao.save(this).  Not sure how you
> could do the class method like find though.
>
> But I agree though, the Ruby/Rails way of having the domain object populate
> itself, persist itself, etc., seems more natural, but there''s
nothing
> special about Ruby/Rails that makes that work.  It can be done in
Java/J2EE,
> and I''m just wondering if there is a reason why it hasn''t
been done that
> way.
>
>
>
> On 4/13/06, Jordan McKible <jmckible@gmail.com> wrote:
> > Paul Barry wrote:
> > > user.save()
> > >
> > > or
> > >
> > > userDao.save(user)
> >
> > 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 user.save().
> >
> > In frameworks like Spring, only the service layer has access to the
DAOs
> > and therefore userDao.save(user) 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.
> >
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>