我实现的实际解决方案使用混合方法。
使用定义明确的查询的方法（例如，其他服务内部使用的方法，预定义的报告等）的签名类似于HibernateTemplate的findBy方法：
public List<Entity> findEntities(String queryName, QueryParameters parameters);
其中
QueryParameters是一个方便类，用于显式指定命名参数或从Bean中获取它们。用法示例为：
List<Product> products = findProducts("latestUpdates", new QueryParameters() .add("vendor", "Oracle") .add("price", "50.0"));要么
List<Product> products = findProducts("latestUpdates", new QueryParameters(product, "vendor", "price"));对此类方法的访问仅限于“可信”代码；显然，必须在Hibernate映射中定义使用的查询。过滤器内置于查询中或定义为会话过滤器。这样做的好处是代码更简洁（没有类似Criteria的内容散布在半页上）和明确定义的HQL（更容易在必要时优化和处理缓存）。
暴露给UI的方法或需要更加动态的方法，请使用Hibernate-Generic-
DAO项目的Search界面。它与Hibernate的DetachedCriteria有点相似，但具有几个优点：
可以创建它而不必绑定到特定实体。对我来说这很重要，因为实体接口（用户可见的API的一部分）和实现（在Hibernate中映射为POJO）是两个不同的类，并且实现在编译时对用户不可用。
这是一个经过深思熟虑的开放界面；与DetachedCriteria完全不同，后者几乎不可能从中提取任何内容（是的，我知道DC并非为此目的而设计的；但仍然如此）
内置分页/带有总数的结果/一堆其他小细节。
与Hibernate没有明确的联系（尽管我个人并不十分在意；我不会突然放弃Hibernate并明天使用Eclipselink）；有可用的Hibernate和通用JPA实现。
可以将过滤器添加到服务端的“搜索”中；那也是指定实体类的时候。唯一缺少的是，如果指定了无效的属性名称，则客户端会快速失败，这可以通过编写我自己的ISearch
/ IMutableSearch实现来解决，但我还没有解决。
