title: How to use object oriented programming with Hibernate?
body: <p>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? </p>
  
  <p>My stack includes Spring with Hibernate for DI, transactions, and persistence. My DAOs are injected into my service layer, not into any POJOs.</p>
  
  <p>Recently I read Martin Fowler's <a href="http://martinfowler.com/apsupp/accounting.pdf" rel="noreferrer">accounting patterns</a> 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. </p>
  
  <p>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.</p>
  
  <p>In Martin Fowler's accounting patterns document, he describes a base class of <code>AccountingEvent</code>. This class might have subclasses such as <code>UsageEvent</code> and <code>InstallationEvent</code>. </p>
  
  <p><code>UsageEvent</code>:</p>
  
  <ul>
  <li><code>UsageEvent</code> occurs when a meter reader records your electricity usage </li>
  <li>Customer's <code>ServiceAgreement</code> is looked up</li>
  <li>The appropriate <code>PostingRule</code>s 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 <code>PostingRule</code>s exist for any given type of event.</li>
  <li>The <code>UsageEvent</code> and <code>PostingRule</code>s determine what actions need to take place, such as creating one or more <code>AccountingEntry</code> objects.</li>
  <li>An <code>AccountingEntry</code> is created to bill for the usage with logic contained in the <code>PostingRule</code>. This could be as simple as <code>rate * usage</code>, but is probably much more complex, based on time of day, commitment levels (big businesses might get discounts), low income households, etc.</li>
  <li>Additional <code>AccountingEntry</code>s are created to bill for taxes, provide credits, etc.</li>
  </ul>
  
  <p><code>InstallationEvent</code>:</p>
  
  <ul>
  <li><code>InstallationEvent</code> occurs when a technician activates power to a building.</li>
  <li>Service agreement and <code>PostingRule</code>s are found</li>
  <li>Appropriate <code>AccountingEntry</code>s are created</li>
  <li>Much different logic and rules are used than in <code>UsageEvent</code></li>
  </ul>
  
  <p>The point is that there are many different types of <code>AccountingEvent</code>s and <code>PostingRule</code>s, 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 <code>someAccountingEvent.process()</code>.</p>
  
  <p>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?</p>