一次关于简化DAO设计的初步思考！

这个显然是不够的，你需要解析的，例如我可能传入对象参数

所以需要提供一个ParameterCfg或者QueryCfg来补充ReadOnly的方法，可以提供一个类型检查机制。参数检查也可以提供。

换成JDO又如何，成本太高了，不可移植性是肯定的，当然我们不一定需要这个移植性
你这种方法就是利用所有其他存储机制去实现Hibernate的NamedQuery机制

还有我说的返回值的类型，传入参数的强类型检查，文档化，这些东西更加重要，这是程序的可理解性和可维护性

我想在实际项目实施中，这个复杂查询统一接口/处理器的实现还是很有诱惑性的，至少我觉得它易于扩展。易于维护。

大系统开发的一个很重要的关键是“显式”编程，灵活性（可扩展性）往往以损失这种“显式“性为代价，所以灵活性的运用是要有一定限度的。

这点我深有体会，有时候为了灵活的使用反而失去了许多OO的基本原则。很容易让我误入歧途，而且直至着火入魔才醒味过来，不知道这算不算以前写C程序落下的老毛病。
我这里着重点了“使用'，它跟扩展还是有比较本质的区别的。

倒是觉得以前在JavaWorld上看到的一篇关于用Command Pattern实现DAO模式的文章值得借鉴..........
在结合ORM的产品的基础上再去做一个复杂的DAO觉得确实有些过了，毕竟ORM已经提供了基本的CRUD的功能，结合Command Pattern实现是个好想法，不过还没试过，目前还是结合HibernateDao实现相应的EntityDao的做法

NamedQuery不是Hibernate特有的, Hibernate, JDO, iBatis, 以及EJB3规范, 都有这个东东. 偶做Map -> JDO, iBatis的实现就是了.

至于意义, 参数类型这些嘛, 偶在最初就说过了, 用Map就没有什么类型安全可言了, 看你的取舍了.

哦，虽然我不懂hibernate和jdo（别打啊！），我还是麻着胆子插播一句：

我希望能够实现下面这种形式的东西：

// 事务对象
class Transaction;
// 查询对象
class Query;
// 表
interface Table;
// 业务对象
interface Business {
  bool mapTable(Table table);;
}
// 业务对象Policy
class Policy extends Business;
// 业务对象Endorment
class Endorment extends Business;

// 组织查询
Query query;
Policy ply;
Endorment edr;

// 例如：
query.need(ply.plyNo,edr.edrNo);.onCondition(ply.edrNo);.enqual(edr.edrNo);;

// 执行事务
Transaction transaction;
transaction.monitor(query.excute(););;

内部实现另考虑

楼上说的东西基于sql类似的东西已经有了：
http://joe.truemesh.com/squiggle/tutorial.html
参考一下就可以完成要求并在其基础上扩展。

其实我一直都有简化DAO API的想法，和firebody原先的思路一样，期望通过简单的DAO接口实现大部分的数据库操作。但是我和firebody的想法不一样的地方在于我认为查询条件的构造应该脱离session。因此我所想到的最直接的方式就是HQL生成器。作为一种工具存在于业务逻辑层，专门根据formbean生成对应的HQL语句。然而等到我最了一个比较简单的HQL生成器以后，发现HQL是解决不了所有的问题的（比如，Hibernate分页，延迟加载都无法脱离session通过HQL直接表示出来），结果是我还要维护大量的DAO。

所以，我还是比较同意potian的意见，DAO不该被简化，当然，除非你认为拼凑HQL或者SQL可以解决大多数的问题，那么开发一个纯面向对象的查询语句生成器才有必要。