Quoting Geert Pante <geertpante@...>:

> --- In domaindrivendesign@yahoogroups.com, Jing Xue <jingxue@...> wrote:
> Hi Jing,

Hi,

> I remember struggling with this for a while. One of the first issues I
> had was that Hibernate calls a default constructor of persisted
> objects to find out what the 'unsaved value' of the primary key is.
> This happens _during_ the hibernate sessionfactory construction. If we
> then inject using @Configurable a DAO that depends on the
> sessionfactory, we get a cyclic dependency.

Ah, I see. Yeah, that's a well known "gotcha". I actually even blogged
about it a while ago:
http://www.digizenstudio.com/blog/2006/02/06/the-circular-bean-reference-problem\
-in-spring-20s-arbitrary-domain-object-wiring/

> Further, it didn't seem to be a good idea to intercept constructors.
> 90% of all loaded domain objects are read-only. The injected services
> are only needed when the domain object needs to change state. For
> performance reasons, we decided to inject lazily, and intercepted the
> getBlaBlaService() method in the Domain Object.

Indeed, that's another valid approach which I toyed around for a
little too, but in the end there are just some issues I can't get
myself comfortable with (maybe you can help me sort out some of these
as I'm sure you've thought it through):

1. Intercepting getAService() would mean that the code everywhere
needs to remember to call getAService() instead of using this.aService.

2. From performance standpoint, every time getAService() gets called,
it has to call getBean().

3. There are many cases where services aren't necessarily for
modifying an object, but for the object to performance its part of the
domain logic. For instance, we had this User class that had a
PasswordHashStrategy injected (not strictly a service, but as
meaningful in this context) to handle password hashing.

Cheers.
--
Jing