Back Forum Reply New

Injection inside domain object

Domain-Driven Design promotes us have behavior in our domain objects. Say if my domain object needs to get another domain object using DAO. The DAO would then need to be injected to the domain object.

Is there any best practice on this area? Because most examples I've seen are dependency injection among singletons.

You might have a look at this chapter in the reference which covers your question.

Regards,
Andreas

You may also want to consider the DataMapper Enterprise pattern which works well with the domain driven design model. It provides a layer between the domain and your datasource that ensures that you domain is not aware of databases

As the pattern indicates, the mapper is not known to the domain layer. Therefore the domain layer cannot access it to access the database. So I guess using this pattern (though being useful in it's own right) might not satisfy the original posters needs.

Chris Richardson gave a presentation 'Building applications With Spring' in this year's SpringOne:

Drawbacks of dependency injection with @Configured
– Requires AspectJ load-time weaving #8658; increased startup time
– Compile-time dependency on Spring #8658; not POJO
– Can’t “unit” test code that instantiates an @Configured entity
Alternative approach:
– Use Hibernate Interceptor to inject entities loaded by Hibernate
– Code that instantiates entities does dependency injection
Use @Configured only when you don’t have control over
object instantiation

So is dependency injection using @Configured a bad idea?

with Ramnivas that talked about this.


Originally Posted by ballsuenSo is dependency injection using @Configured a bad idea?

Personally I have not used it yet in a project, and I am also no overeager adopter of annotations. I use them, but judiciously.
That said: when I would face a situation where I really need dependency injection into domain objects, then @Configurable surely provides a poweful solution. In my opinion it just should not be the first solution to take in every case.

Just my 2 cents,
Andreas

There was a discussion about DDD a good while ago that talked about a way of doing this, I think this was a Hibernate specific approach though, so if that's useful you might want to have a search on there.

Are you referring to the approach using hibernate interceptors? Now that you mention it, I remember. That might indeed be a good alternative when using hibernate (which I currently prefer as ORM solution).

Thanks for the reminder,
Andreas


Originally Posted by Andreas SenftPersonally I have not used it yet in a project, and I am also no overeager adopter of annotations. I use them, but judiciously.
That said: when I would face a situation where I really need dependency injection into domain objects, then @Configurable surely provides a poweful solution. In my opinion it just should not be the first solution to take in every case.

Very true. Personally I found that when I am using ORM frameworks like Hibernate, in most of the cases I am able to access related entities by navigating associations. Hence there are very few cases where I may need to use @Configurable.

And, while we are on the topic of @Configurable, does anyone in the forum has any experience of performance problems using @Configurable with large datasets. Typically when we inject into a domain entity, we use it in one or two methods for specific functions, while for injection, @Configurable intercepts the constructor. There may be many cases where most of the time I will not be using the injected service / repository / DAO, yet the injection will take place, since the constructors are getting intercepted. Can a get() joinpoint provide a more optimum solution ?

Cheers.
- Debasish
¥
Back Forum Reply New