In this example, we are trying to get the net worth of a Customer object. A Customer object has a relationship with an Account object, but it only has a reference to the Account object's id:
public class Customer {
private Long accountId;
public Long getAccountId() {
return accountId; }
}
public void setAccountId(Long accountId) {
this.accountId = accountId;
}
...
}
The value of the account is used to determine the customer's net worth. Suppose we have a CustomerService interface that exposes this operation via its getNetWorth(Customer) method. One implementation of this method would be to place most of the logic in the service layer like this:
public Double getNetWorth(Customer customer) {
Long accountId = customer.getAccountId();
Account account = accountRepository.getAccountById(accountId);
return account.getValue();
}
This is a classic example of an anemic domain model. All of the business logic is in the service layer and the domain objects are simply data containers. But in OO, an object = data + behavior, right? So how do we push this behavior back to the domain layer?
This biggest question in this particular scenario is how can a Customer object obtain a reference to its Account object? Well, there are several ways:
- It could be given a reference to the Account object by the CustomerService object. But that really isn't much different than the example above. The CustomerService class is still two involved in the business logic.
- This Customer object could actively obtain a reference to the AccountRepository via a service locator. But this introduces a dependency not only on the AccountRepository, but the service locator as well - not a very transparent solution.
- The AccountRepository object could be supplied to the Customer object using dependency injection. This makes sense - after all, we are doing this with our Spring beans already in our service/data access layers.
@Configurable("smartCustomer")
public class SmartCustomer extends Customer {
private AccountRepository accountRepository;
public AccountRepository getAccountRepository() {
return accountRepository;
}
public void setAccountRepository(AccountRepository accountRepository) {
this.accountRepository = accountRepository;
}
public Double getNetWorth() {
Account account = accountRepository.getAccountById(getAccountId());
return account.getValue();
}
}
Now a Customer object can obtain a reference to its associated Account object via the AccountRepository. But how does it obtain a reference to the AccountRepository? Notice the @Configurable annotation. This is basically a marker that identifies this class as needing to be configured by Spring whenever a new instance is created. This "magic" is possible because AspectJ weaves in advice into the SmartCustomer's constructor. I have not delved into the details, but I suppose this advice is aware of the Spring application context.
Spring knows how to configure each instance of this class from a prototype bean configured in the application context:
<bean id="smartCustomer" abstract="true" class="org.springdallasug.aspectj.domain.SmartCustomer" scope="prototype" >
<property name="accountRepository" ref="accountRepository" />
</bean>
Now every instance of the SmartCustomer class will be wired with an AccountRepository object. In order to make this happen, AspectJ must weave this advice into the SmartCustomer class. For my demo, I chose to use load time weaving. This is done by starting the JVM with the following option:
-javaagent:PATH_TO_JAR/aspectjweaver-1.5.0.jar
This enables AspectJ to weave advice into classes as they are being loaded into the JVM. For anybody interested, I have packaged up this simple demo. The entire mechanics behind this can be found in the Spring documentation.
So, it is pretty cool that Spring + AspectJ makes it straightforward to apply dependency injection to domain objects. But the question remains, is this the right thing to do? Taking the example above, allowing a Customer object to completely contain the logic of calculating its own net worth means it needs access to its Account object. But this, in turn, means giving it access to the AccountRepository. This is, for me at least, an unusual design decision. While this does create a "richer" domain model, at adds more (potentially complex) dependencies into the domain model.
I don't think the answer is cut and dry. Instead, it probably needs to be fleshed out in a "real world" application. I just might have to try that.
Edit:
Craig Walls pointed out a couple of improvements to this example. First, I added the name of the prototype bean to the annotation to be more explicit (I also added the "id" attribute to the SmartCustomer bean in the Spring configuration file). Second, I made the prototype bean abstract, which prevents the Spring container from ever instantiating an instance - it is now strictly a prototype. Not a big thing, but it is an improvement. Thanks Craig.
