Question

While using ORM tools such as Hibernate, I’ve found it is advantageous to keep all business logic out of my business objects and instead keep it in a service layer. The service layer creates the business object POJOs, manipulates them, and uses DAOs to save them. But isn’t this in a way taking a step backwards from the object oriented nature of Java?

My stack includes Spring with Hibernate for DI, transactions, and persistence. My DAOs are injected into my service layer, not into any POJOs.

Recently I read Martin Fowler’s accounting patterns document on building flexible accounting systems. I believe it was written before the Spring/Hibernate/DI/ORM craze. It describes objects that contain business logic. These objects use inheritance and composition in elegant ways that make sense.

By putting the logic into classes, it can be partitioned into neat units that only pertain to one specific scenario. In my service layer I end up having lots of different methods, each which deals with a different scenario. But it is far from object oriented.

In Martin Fowler’s accounting patterns document, he describes a base class of AccountingEvent. This class might have subclasses such as UsageEvent and InstallationEvent.

UsageEvent:

• UsageEvent occurs when a meter reader records your electricity usage
• Customer’s ServiceAgreement is looked up
• The appropriate PostingRules are found in the service agreement for this type of event and for this particular time period. Rules and rates can change over time, so multiple PostingRules exist for any given type of event.
• The UsageEvent and PostingRules determine what actions need to take place, such as creating one or more AccountingEntry objects.
• An AccountingEntry is created to bill for the usage with logic contained in the PostingRule. This could be as simple as rate * usage, but is probably much more complex, based on time of day, commitment levels (big businesses might get discounts), low income households, etc.
• Additional AccountingEntrys are created to bill for taxes, provide credits, etc.

InstallationEvent:

• InstallationEvent occurs when a technician activates power to a building.
• Service agreement and PostingRules are found
• Appropriate AccountingEntrys are created
• Much different logic and rules are used than in UsageEvent

The point is that there are many different types of AccountingEvents and PostingRules, each of which knows precisely what to do for a specific situation. These objects are easily interchangeable using interfaces. I can kick of everything by simply issuing the command someAccountingEvent.process().

I’m unclear on the best way to get some of this elegance back when I have to create and save entities within the service layer. I don’t want to inject my DAOs into my POJOs, which would add extra dependencies to them and potentially make them much heavier weight objects. But how would I best model something like this in my service layer where I can inject DAOs?

Answer 1

You might be talking about what’s referred to as an "Anemic domain model". I have previously answered a question on the topic which points to a blog article about how to inject services into model instances which Hibernate it retrieving.

Spring and the Anemic Domain Model

The referenced blog article is Domain Driven Design with Spring and Hibernate