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?
on 2006-04-13 21:23
on 2006-04-13 21:56
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.
on 2006-04-13 22:06
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 2006-04-18 17:42
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.