I asked Eric Evans (author of Domain Driven Design) about whether a domain object (or an Entity as he calls it) should hold a reference to a DAO (or a Repository as he calls it), as in my parent/child example that started this forum topic. My question and his answer are posted here: http://groups.yahoo.com/group/domain...n/message/2305.
To summarize, his answer was that the client of the parent domain object should hold the reference to the DAO that loads that child domain objects. In other words, the parent would NOT hold the reference and would NOT need to be injected with the DAO dependency. I found his answer to be somewhat surprising because he is a huge proponent encapsulating both data and behaviour in domain objects.
Ideally, it would be nice to encapsulate the DAO in the parent but it seems from the answers in this discussion that this may not be practical because of potential problems with DI, transactional demarcation and serialization. In particular, I'm a bit nervous to try the HibernateInterceptor solution...it seems a bit too magical to me.
FYI, you guys really should read Rod Johnson's posts about hydrating Hibernate objects that cepage referred to above.
"All your bean are belong to us" - Spring Framework's IOC Container