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?
Paul B. 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.
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.
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.