讨论：Dao查询接口设计经验

用Map作参数才是王道！用对象的话太死板

List query(String sql,Map conditions); 方法不错，接口比较稳定。

   这种方式不太好吧，接口不够清晰，而且需要其他类的配合，不够内聚，我觉得hql倒是不一定要作为入参，但查询条件最好要作为入参。

我一直用对象来传递的,一般都是判断其属性是否为空或者大于零,成立我就根据这个条件来查询,这样对一般的查询都可以用一次做完.至于一些类似报表的查询,一个查询一个方法,呵呵

可以用一个基类的pojo做参数

？不见得
用来查询用pojo 也可以办到
或继承后加几个参数吧。。。。

    不见得，Map 作参数虽然灵活了，稳定了。

     但是其缺点同样显而易见：方法本身的成功运行
完全依赖于Map 中被放入的东西，当Map中被意外的放入的
不该放入的参数或者缺少了一个参数，会出现令人讨厌的难以
查找的异常。

     Map只是适合于查询条件本身就是灵活的，不确定的情况。
当查询接口本身就是确定的情况下应该使用对象参数查询，否则
很容易造成Map被滥用的情况
    

JDK5.0中提供的不定数入参,是什么概念啊？

我通常设计成如下的结构!

有2个关键

1:把查询条件封装起来
2:保持接口的健壮,也就是说保证业务接口关注方向

public class ObjectQueryHandleFactory {
   public ObjectQueryHandler openQuery() { ... };
}

public class ObjectQueryFilterFactory { 
   public ObjectQueryFilter openFilter() { ... }; 
}

public class ObjectQueryHandler{}

public class ObjectQueryFilter{}

public class PersonQueryHandler extends ObjectQueryHandler{}

public class PersonQueryFilter extends ObjectQueryFilter{}

public class StreatQueryHandler extends ObjectQueryHandler{}

public class StreatQueryFilter extends ObjectQueryFilter{}

Dao设计

ObjectDaoGet(ObjectQueryHandler oqh, ObjectQueryFilter oqf) {};

这样把Query数据封装在ObjectQueryHandler这个模块组里,把Query逻辑封装在ObjectQueryFilter模块组里.处理起来非常灵活,还有一个非常吸引人的特性就是可以把工作丢给别人!由于你提供的只是封装,具体实现有每个开发人员自己掌握,自己的工作量少了很多，别人也不会太介意.同时也可以消除统一接口上引起的效率和业务接口被滥用的问题.

比如

public class dynaProxyHandleBuffer()

来加强一下我某一类的结构,而在只需要通过一项申明式的字段来标示.

ObjectQueryHandler.setPropertys(new ObjectrProperty(){.......})

可以设计为一个示例查询不,它可以自动处理空的参数,但是要查询一个时间段内的数据还需要一个高手来解决