In my
last post, I discussed the possibilty of using AspectJ with Spring to inject domain objects with service objects to create a richer domain model. This follow up is to explore some example code based on a Customer -> Account example given by
Ramnivas.
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.
Implementing option #3 is where AspectJ comes in. While Spring manages the lifecycle of service and data access beans, it does not manage the lifecycle of domain objects. These can be instantiated via
new or by another framework, such as Hibernate. However, AspectJ
can weave advice into the domain object's classes that is executed after their constructor completes. There are several pieces to this puzzle. First let's take a look at the "enriched"
SmartCustomer class:
@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.jarThis 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.
