在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去描述我们想要查询的记录。