Spring 2.0 vs. the Anemic Domain Model
One of the most interesting aspects (no pun intended) of Spring 2.0
That was discussed this past week at The Spring Experience was the idea
Of letting Spring configure beans post-instantiation and regardless of
How the bean became instantiated. This Spring 2.0 feature helps avoid
The Anemic Domain Model” anti-pattern as described by Martin Fowler.
It’s very common in Spring to build applications where service objects
Are injected with DAO objects and use those DAO objects to handle
Persistence of domain objects. The domain objects themselves, however,
Are little more than dumb data holders. The problem with this approach
Is that the interaction between the service object and the DAO object
Is very procedural. The service object makes one or more calls to the
DAO, passing the domain object around like cargo.
Ideally, the domain object would contain behavior to handle its own
Persistence. If domain objects offered such behavior, then the service
Object could deal directly with the domain object in a very
Object-oriented way. Instead of telling a DAO to persist a customer,
The service would tell the customer to persist itself. There will still
Be a DAO, but the domain object will do its own dealing with the DAO,
Unbeknownst to the service object. In effect, the domain object and the
DAO swap positions with relation to the service object.
If the domain object is responsible for dealing with the DAO, then the
Domain object must have access to the DAO. In Spring, we’d like to do
This through dependency injection. But domain objects are typically
Instantiated outside of Spring (e. g. in Hibernate, iBATIS, or some
Other persistence mechanism). How can Spring inject a DAO into a domain
Object when Spring isn’t the one instantiating that domain object?
/> AspectJ to the rescue
If there was any common theme expressed during The Spring Experience
Last week it was that AspectJ is going to play a huge part in Spring
2.0. Indeed, the addition of Adrian Colyer to the Spring team has
Triggered a large number of AspectJ-related enhancements. While Spring
AOP is nice, AspectJ offers a great deal of potential that cannot be
Found in proxy-based AOP.
One of the AspectJ-powered enhancements is the inclusion of
Org. springframework. beans. factory. aspectj. BeanConfigurer.
BeanConfigurer is an AspectJ aspect that performs dependency injection
On objects after instantiation…even objects that aren’t instantiated
By Spring. Let’s take a look at BeanConfigurer in action.
Imagine an application that (among other things) maintains a database
Of customers. In such an application, you may have a Customer domain
Object that looks like this:
Public class Customer {
private Integer id;
private String name;
Public Customer() {}
Public Integer getId() {
return id;
}
Public void setId(Integer id) {
this. id = id;
}
Public String getName() {
return name;
}
Public void setName(String name) {
this. name = name;
}
}
(NOTE: I’ve purposefully kept the Customer class simple with only ID
And name properties so as not to clutter the example with unnecessary
Noise. In a real-world application, this class would likely have many
More properties.)
Notice that the Customer class doesn’t have any real
Functionality – It’s merely a data holder. This is what the Customer
Class might look like in a pre-2.0 Spring application. It’s assumed
That instances of Customer will be passed around to a CustomerDao
(1 votes, average: 5.00 out of 5)