title: Java EE Architecture - Are DAO's still recommended when using an ORM like JPA 2?
body: <p>If I'm using an ORM like JPA2 - where I have my entities that are mapped to my database, should I still be using a DAO? It seems like a lot more overhead.</p>
  
  <p>For example, I would need to maintain three extra packages:</p>
  
  <ol>
  <li><p>One that specifies my domain objects (which pretty much map my Entity objects):</p>
  
  <pre><code>public class Employee {
      private String firstName;
      private String lastName;
      ...
      // Getters and setters
  }
  </code></pre></li>
  <li><p>One that contains interfaces that specify my DAO methods</p>
  
  <pre><code>public interface EmployeeDAO {
      public void addEmployee(Employee employee);
      public Employee getEmployeeById(long id);
      ...
  }
  </code></pre></li>
  <li><p>One that contains session beans that implement my DAO's</p>
  
  <pre><code>public EmployeeJpaDAO implements EmployeeDAO {
      interface method implementations here
      ....
      private method that transform my Employee entity into my Employee domain object
  }
  </code></pre></li>
  </ol>
  
  <p>Now that's a lot of extra baggage to add every time I need to perform a new CRUD operation.</p>
  
  <p>However the benefits I see from having a DAO is:</p>
  
  <ol>
  <li><p>You can have an in memory implementation of the DAO for unit testing your service layer. This means you don't need to access the database to test business logic, and you can be assured that your objects will always contain the same values for properties</p></li>
  <li><p>It separates business logic from database access logic</p></li>
  </ol>
  
  <p>The option that doesn't involve implementing a DAO is to just use entity objects and EntityManager in the service layer:</p>
  
  <pre><code>@Stateless
  public class EmployeeEjb {
      @PersistenceContext(unitName = "employee")
      private EntityManager manager;
  
      public Employee getEmployeeById(long id) {
          return manager.createNamedQuery(Employee.GetEmployeeById).getResultList();
      }
      ...
  }
  </code></pre>
  
  <p>Is there no middle ground here? Has anyone come across an architecture or implemented an architecture that meets some of the benefits of a DAO layer (most importantly the unit testability of business logic) that I mentioned above, but doesn't involve all the overhead involved to implement a DAO layer?</p>
  
  <p>Thanks for any recommendations and/or suggestions! I'm really curious to see what some people have come up with in regards to this.</p>