在Java軟件項目中常常將持久層抽象成DAO，因為JDBC、甚至是Hibernate等ORM框架都不能提供足夠簡便和純粹的面向對象的數據庫操作，而將底層的數據庫操作抽象成DAO層之后，能往上提供一致的簡單的接口，對于項目的可維護性和復用都有很大的意義。
        但是在一次又一次的項目開發中，我們都必須重新編寫DAO層，有人覺得這是在對底層操作封裝、是一項愉快的工作，但是我認為這是一項目重復的、應該想辦法避免的工作，之所以要為項目設計DAO層，是因為現今的ORM框架不夠完善，只是對JDBC的簡單封裝，導致當我們想以一種面向對象的方式簡單地實現持久化操作時，只能通過自己編寫DAO。難道持久層框架的作用不能擴大到讓DAO從我們的視野中消失嗎？
        為了說明上面的問題，我舉一個簡單的例子：
        假設一個論壇需要一個“根據用戶名字查詢該用戶的所有信息(User對象)”的功能，我們不是守舊的JDBC派，我們在項目中應用了Hibernate，但是，Hibernate仍然不能很好地完成這個任務，為了查出這個用戶，我們需要寫丑陋的HQL語句，需要打開Session。沒有人愿意一次又一次地編寫這些重復的代碼，于是我們把這些笨重的過程封裝成了一個函數 getUserByName(String)，這個函數自然是屬于一個DAO的，于是DAO層理所當然地擁有了立足之地。現在請考慮這樣一個問題，如果我們用的不是Hibernate，而是另一個持久層框架，假設它的名字叫AliveRecord，它提供了這樣的查詢功能find(Filter filter),Filter類以一種簡單的方式描述了你的查詢條件，于是“根據用戶名字查詢該用戶的所有信息(User對象)”這個功能只需要一行代碼就能實現，在這樣的情況下，你還會花無謂的時間去專門寫一個DAO嗎？
        總結上面的問題，我們需要一個不僅能提供持久化操作、而且其使用方式簡單到可以替代DAO的框架。
        但是要設計這樣一個框架，除去性能等因素，還有一個非常艱巨的問題：如何使用Java語言表達SQL語句的語義？大家知道，SQL是解釋語言，非常靈活，可以構造極度復雜的查詢條件，而在持久層框架中，要想不新增HQL、EJBQL等類SQL的語言、單純用Java去描述我們想要查詢的記錄。