Az eredeti (régi) J2EE specifikáció hívta életre a DAO tervezési mintát, melynek lényege pusztán annyi volt, hogy teljesen elválassza az üzleti logikát a fizikai adatbázistól. Azonnal látszik, hogy a DAO még a Hibernate és a JPA előtt jött létre, s azt is látszik, hogy a Hibernate a DAO hiányosságait pótolta, a JPA pedig Hibernate által adott út újragondolásával született meg. A DAO alapvető feladata az volt, hogy az adatbázisból előszedje a kívánt adatokat, és azokból entitás beaneket gyártson, majd az üzleti logikának adja ezen entitások halmazát. További feladata a módosított entitások adatbázisban való visszaírása, illetve a többi - adatbázisban megszokott művelet - elvégzése.

A JPA entitás menedzsere viszont szükségtelenné tette a DAO osztályokat, mivel OQL nyelven - adatbázis függetlenül - egy sorban megoldható az, amire eddig DAO osztályt készítettünk. Az üzleti logika pedig két soban megörökli az aktuálisan használt entitás menedzsert:

@PersistenceContext
private EntityManager em;

Vannak azonban jelentős érvek a DAO mintáta megtartása mellett:

• ne keverjük ismét össze az üzleti logikát az adatok elérésével, a komplex lekérdezések nem az entitás beanbe valók, és nem is az üzleti logika részei, ezeknek DAO osztályban a helyük
• minden réteg tegye a dolgát, hiszen annak idején azért született a négy rétegű modell, hogy jól el tudjuk választani a feladatokat (üzleti logika, adatkezelés, adattárolás)
• jobb a kódolvashatóság, ha nem kell gondolkodnunk azon, hogy a lekérdezéseink hol vannak (üzleti logika vagy entitás)
• le legyen infrastruktúra az üzleti logikában, ez gondot okozhat fürtözés esetén