DAO Reference Inside an Entity Domain Object?

Quote:

---

Originally Posted by cyboc

Are any of the heavyweights (e.g. Rod and Colin) going to chime in on this discussion?

---

They tend to get real quiet on this point. It underscores a weakness of the framework; namely, it is sometimes difficult to perform injection on domain objects.

Ben goes so far as to suggest that allowing a domain object to reference another Spring service is bad design. I respectfully disagree with that view.

In http://forum.springframework.org/showthread.php?t=9846, Rod offers a solution for hydrating Hibernate objects, but it is only halfway implemented, and a final implementation is not scheduled until Spring 1.4.

I know it's not an easy problem to solve, but I wish it was a higher priority issue.

Quote:

---

Originally Posted by cepage

In http://forum.springframework.org/showthread.php?t=9846, Rod offers a solution for hydrating Hibernate objects, but it is only halfway implemented, and a final implementation is not scheduled until Spring 1.4.

---

As far as I tried it, it works with no problems whatsoever.

I think as previously stated, one of the biggest hurdles is the injection of run time services.

One of the important points to consider is what is actually going to happen with your domain object. If it will ever be serialized and de-serialized in another environment (replication, webflow-flow scope) then you *really* do not want to keep a handle on the dao.

I do not have a *nice* solution for this, and yes it would be really nice if there was a way of having all these things transparently injected for you.

BTW; I would still consider using an interface because it seems the child loading strategy isn't an inherent part of the parent.

If you *do* want magic injection (which again, I would think very carefully about) then you can always have an interface:

HibernateAware {
setSession(final Session session);
}

and have a HibernateInterceptor applied to every hibernate backed object .

What would be *really* nice is if we could get spring to load the hibernate objects for us and apply dependency injection, i.e. if the object you got out of hibernate was actually a spring proxy which did nothing other than dependency injection. Of course this isn't possible but hey ;)

Quote:

---

Originally Posted by yatesco

I think as previously stated, one of the biggest hurdles is the injection of run time services.

One of the important points to consider is what is actually going to happen with your domain object. If it will ever be serialized and de-serialized in another environment (replication, webflow-flow scope) then you *really* do not want to keep a handle on the dao.

I do not have a *nice* solution for this, and yes it would be really nice if there was a way of having all these things transparently injected for you.

BTW; I would still consider using an interface because it seems the child loading strategy isn't an inherent part of the parent.

If you *do* want magic injection (which again, I would think very carefully about) then you can always have an interface:

HibernateAware {
setSession(final Session session);
}

and have a HibernateInterceptor applied to every hibernate backed object .

What would be *really* nice is if we could get spring to load the hibernate objects for us and apply dependency injection, i.e. if the object you got out of hibernate was actually a spring proxy which did nothing other than dependency injection. Of course this isn't possible but hey ;)

---

This is exactly what DependencyInjectionInterceptorFactoryBean does.
Serialization/deserialization problem can be partially solved by using "transient".

Quote:

---

Originally Posted by dejanp

As far as I tried it, it works with no problems whatsoever.

---

It only works with Hibernate2, and it only works with a couple of methods, like session.load(). Using methods like query.list() or creating an object in Hibernate do nothing, and you need to inject yourself.

I believe that Rod is, correctly, taking a step back and trying to figure out a more holistic approach to this problem than playing whack-a-mole with Hibernate API's.

cepage: Cool description "playing whack-a-mole with Hibernate API's." :)

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.

Quote:

---

Originally Posted by cyboc

FYI, you guys really should read Rod Johnson's posts about hydrating Hibernate objects that cepage referred to above.

---

Oh, yah, also check out these:
http://thread.gmane.org/gmane.comp.j...work.user/3402
http://thread.gmane.org/gmane.comp.j...work.user/3513

Excellent thread. The related reading is also very good.

My conclusion is that the neatest way (not ideal, but best of the bunch) is to provide the collaborator to the method call.

Quote:

---

Originally Posted by cepage

Quote:

---

Originally Posted by dejanp

As far as I tried it, it works with no problems whatsoever.

---

It only works with Hibernate2, and it only works with a couple of methods, like session.load(). Using methods like query.list() or creating an object in Hibernate do nothing, and you need to inject yourself.

I believe that Rod is, correctly, taking a step back and trying to figure out a more holistic approach to this problem than playing whack-a-mole with Hibernate API's.

---

Making it H3 compatible is trivial. DI on list() and such works, of course - the whole thing would be useless otherwise. If you create your objects, there is no injection, as usual. If you use prototype driven injection (and you should, autowire is not exactly performant) you can fetch new instances from the context, like any other bean.