Domain Object Dependency Injection with Spring
I have always considered domain objects as dumb because they normally don't do anything i.e. they don't have any behavior. But with the advent of Domain Driven Design, the same domain objects have got the power to do useful things. In order to do something useful, they have to collaborate with other classes i.e. they will have dependencies on other classes . The problem is that Domain objects are either created using the new operator or by an ORM framework so as to inject beans into it. For example, we have a User entity and we want to add a behavior like findAllUsersWithSameLastName into the User entity as shown below
public class User implements Serializable {
private String firstname;
private String lastname;
private MyDao myDao;
public List<User> findAllUsersWithSameLastName(){
return myDao.findAllUsersWithLastName(this.lastname);
}
// setters and getters
}Now in order to inject myDao bean inside User entity, we have to mark the User class with @org.springframework.beans.factory.annotation.Configurable annotation which makes the User class eligible for Spring driven configuration. The core idea behind domain object DI is : An AspectJ-woven aspect selects join points corresponding to creation or deserialization of any object matching certain specification. Advice to those join points inject dependencies into the object being created or deserialized.
@Configurable
public class User implements Serializable {
private String firstname;
private String lastname;
@Autowired
private MyDao myDao;
public List<User> findAllUsersWithSameLastName(){
return myDao.findAllUsersWithLastName(this.lastname);
}
// setters and getters
}
Just mentioning @Configurable on the User entity does not make this class Spring configured. You need to have org.springframework.aspects-3.0.4.RELEASE.jar in your classpath. This jar contains a class called AnnotationBeanConfigurerAspect which acts on this annotation . AnnotationBeanConfigurerAspect needs to be configured in spring application context xml to obtain a reference to the bean factory that is to be used to configure new objects. Also, we need to configure the auto scanning of User entity and dao class so that they can be auto-registered. You also need to activate the Spring LoadTimeWeaver which is also present in context namespace.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">
<context:spring-configured />
<context:component-scan base-package="com.shekhar.di"></context:component-scan>
<context:load-time-weaver aspectj-weaving="on" />
</beans>
Last thing that you have to configure is to add the javaagent argument to your JVM or eclipse JUnit run configurations
-javaagent:~\.m2\repository\org\springframework\org.springframework.instrument\3.0.4.RELEASE\org.springframework.instrument-3.0.4.RELEASE.jar
Lets run the test.
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class UsersTest {
@Test
public void shouldConfigureDomainObject() {
User user = new User();
user.setFirstname("shekhar");
user.setLastname("gulati");
List<User> users = user.findAllUsersWithSameLastName();
assertNotNull(users);
}
}
After you run test if you get exception like this
SEVERE: register definition failed
org.aspectj.weaver.BCException: Unable to continue, this version of AspectJ supports classes built with weaver version 3.0 but the class org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect
is version 6.0
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>1.6.9</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.6.9</version>
</dependency>
This feature is not new in Spring; it existed from 2.0 days but I think it is less known. So next time, you think of adding some behavior to your domain object think about dependency injection in domain objects. Although there is documentation on the web about this, it took some time to make it work. I am also attaching the sample project in case you want to play with it.
| Attachment | Size |
|---|---|
| di-domain-objects.zip | 10.38 KB |
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Slava Lo replied on Mon, 2010/11/01 - 4:25am
I can see two issues with this example (maybe not the DDD pattern itself):
1. in order to run search for 'all users with the same last name', there should be some instance of User to call the method. So, in this case it looks like 'chicken or an egg' paradox - how would you get the reference to User on the first place ? (other then creating new instance)
2. Say, you have a list of users with the same last name of about size of 100. Does it mean that there will be overhead of running the aspect-j based injection of dao into each out of 100 instances, while mayby none of them will be used to call that method ?
Mladen Girazovski replied on Mon, 2010/11/01 - 4:51am
This ist not a DDD Pattern, this is the ActiveRecord Pattern, which is quite the opposite of DDD.
DDD advocates the use of a Repository that the User object would access if it needed tosearch for users etc. pp.
Praveen Govindan replied on Mon, 2010/11/01 - 8:48am
in response to:
Slava Lo
Jonathan Fisher replied on Mon, 2010/11/01 - 9:58am
If you're design isn't distributed (ie not SOA or EJB) there is benefit to having active domain objects, otherwise they can cause chaos in large distributed systems.
Alessandro Santini replied on Mon, 2010/11/01 - 10:35am
in response to:
Jonathan Fisher
Jose Maria Arranz replied on Tue, 2010/11/02 - 6:58am
I agree too
That
private MyDao myDao;
into a domain model hurts my eyes, fortunately the code of MyDao is not into the domain model :)
I'm sorry, in my opinion this article about the anemic domain model as an anti-pattern is itself an anti-pattern, any experienced developer knows how much crazy is the rich domain model approach (by the way being proposed very much these days).
Igor Laera replied on Tue, 2010/11/02 - 10:57am
I think, the classical Domain Model approach comes from the illusion you can hide everything behind an object and then only communicate over public interfaces with that object. Public interfaces and behaviours that preferably never change ;)
In an agile world, just calling two different methods on an already instanced object can have completely different pre- and post-contracts, not to talk about different transaction-behaviour. Since Java currently forces the caller to care about exceptions ("throws IOException") but does not to directly ensures any technical or business contract (think: "requires Transaction, requires Instantiation, defines LoginObject, "). This results always in some difference between the intended use and the real use of objects. In large project this gap is part of the nightmare of refactoring huge object trees ("How could this every work without a User and a Product key?")
When I look at big projects right now, I see heavy DTO layers with certain "hot spots"-manager classes (which I find very anti-pattern for different reasons) and then you have (crosscutting) (overlay) use cases combining all that madness into varyingly (un)maintainable code sprinkled with Spring, AOP and everything apache.org has to offer ;*)
I would like to have some sort of large object 'magic idiom' to take care about every possible detail, but at the end the classical User().repository.findxxx() always gets its 20 variations with different behaviours - since there is never enough time/willingness/cookie dough to force the next guy to refactor the other five already there.
For me, this topic moves more and more into how the project (leaders) can enforce a certain style of coding and architectural behaviour. We still have problems to ask hardcore hackers to use Checkstyle, but they should fully get when to do DDD - and when not?
Paul Sydney Orozco replied on Tue, 2010/11/23 - 12:58am
great post. Anyways, i wanna share also a spoon-feed tutorial on Spring MVC http://www.adobocode.com/spring/a-spring-web-mvc-tutorial
and add step-by-step Hibernate JPA capabilities tutorial to it: http://www.adobocode.com/spring/adding-crud-capability-to-spring-mvc
hope it will help people!
Sadsds Dsadsadsa replied on Tue, 2010/12/21 - 4:48am
Rogerio Liesenfeld replied on Tue, 2010/12/21 - 1:13pm
My solution was to use a static persistence facade on top of an ORM API, rather than DAO or Repository objects. So, I could write such a method as simply as the following, where the facade methods are statically imported:
It works really well, with no need for DI.