Weblog of Peter %u201CAlarmnummer%u201D Veentjer - Blog about Spring, Acegi, concurrency and other JEE related subjects.

Interesting thoughts on DDD and a bunch of other interesting stuff for enterprise java dev.

Mike Dunn's Weblog

For the sake of making my domain model richer, I hereby succumb to the convenience brought by DependencyInjectionInterceptorFactoryBean. This doesn't address new objects not fetched from the database. My workaround is to add a newInstance method in the DAO. The newInstance just calls in the same bean that all objects taken from the database used.

for example:
newInstance() {
return ServiceLocator.getImpl("Instance");
}

This requires getting your hands dirty with spring framework CVS as this code currently lives only in the sandbox. And yes, this interceptor relies on springs autowire capability, keep that in mind when naming those beans to be injected into your domain object.


Anyway, if you still want rich domain models but don't want AOP or Dependency Injection via an interceptor, there's always a Service Locator pattern to save your day.

for example:

domainOjbect.doSomething() {
iShouldBeAutoInjectedService = ServiceLocator.getImpl("SpringDefinedBean");

iShouldBeAutoInjectedService.doService();
}

Be wary, that this somehow makes your domain object dependent on service locators. This also works well at scenarios where the auto injected service needs to be defined only during deployment time. Whether or not that is good thing, YMMV.

Why do you need rich domain models? Well, it just goes back to the aim of OOP. Objects that pretty much can do things by themselves. Rich domain objects helps a lot in mapping the meatspace domain problem to your application. It also allows your domain model POJO's to naturally follow design patterns principles, since it is now more than just a bunch of getter and setter methods to access a database fields (a.k.a. anemic domain model). You can inject stuff that allows you to add behaviour to your objects.