通过服务API公开休眠条件

Question

这更多的是设计而不是实现问题，而且会很长，请耐心等待。最好用一个例子来解释：

假设我有一个名为 Product 的业务实体，该实体具有许多属性（ 名称 ， 价格 ， 供应商 等）。

它由一个接口（ 产品 ）和实现（ ProductImpl ，在Hibernate中映射）以及基本的CRUD服务接口（
ProductService ）和实现（ ProductServiceImpl ）表示。
Product 和 ProductService 作为API公开，而其实现则没有。

我想向 ProductService* 添加一个 List findProducts（QueryCriteria条件）
方法，该方法将返回满足给定条件的产品列表。要求是： *

1. 通过直接 产品 属性查询（例如product.price gt 50.0）
2. 按关联查询（例如product.vendor.name = "Oracle"）
3. 排序结果（例如order by product.vendor.name desc, product.price asc"）
4. 应用其他过滤器。与API客户端指定的以上3个项目不同，服务可以基于客户端的身份应用其他过滤器（例如，调用此方法的客户端可能仅限于查看给定供应商生产的产品）。此类过滤器优先于客户端指定的任何条件（例如，如果过滤器设置为product.vendor.name = "Microsoft"，则上述（2）中的查询应生成空结果集。

因此，问题是，这种方法使用的 QueryCriteria 接口应该是什么样？我可以想到3个解决方案，但我不喜欢其中任何一个：

• 允许客户端直接指定HQL（以“ where”子句开头）。这是最直接的解决方案，也是最有问题的安全性。即使假设过滤器（上面的＃4）足够简单，可以通过Hibernate的会话过滤器实现，HQL仍然需要解析为-至少-确保将查询参数指定为参数而不是内联。
• 使用薄包装的Hibernate的 DetachedCriteria 代替 QueryCriteria 。“薄包装”是因为不允许客户端直接创建 DetachedCriteria ，因为无法控制为其创建的映射实体。而且，对于某些查询而言，这不像HQL那样灵活，无法通过Criteria API轻松（或根本无法）表达。与HQL方法一样，过滤器（上面的＃4）将限于Hibernate会话过滤器。
• 编写我自己的 QueryCriteria 接口/实现，该接口/实现将在后台形成DetachedCriteria或HQL。虽然这可能是最灵活的解决方案，但这将不得不复制Criteria API的许多代码，这似乎不太理想。

任何对上述方法的有效性的评论，或者-手指交叉-我没有想到的简单优雅的解决方案，将不胜感激。

PS在我的特定情况下，所有API客户端都是内部的并且是“半信任的”-也就是说，我与试图故意破坏某些内容的人并没有因为编程不良而导致生成5张表的笛卡尔积无关：-)但是，提出一个可以承受API对公众开放的解决方案将是非常不错的。

Answer 1

我实现的实际解决方案使用混合方法。

使用定义明确的查询的方法（例如，其他服务内部使用的方法，预定义的报告等）的签名类似于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有点相似，但具有几个优点：

1. 可以创建它而不必绑定到特定实体。对我来说这很重要，因为实体接口（用户可见的API的一部分）和实现（在Hibernate中映射为POJO）是两个不同的类，并且实现在编译时对用户不可用。

2. 这是一个经过深思熟虑的开放界面；与DetachedCriteria完全不同，后者几乎不可能从中提取任何内容（是的，我知道DC并非为此目的而设计的；但仍然如此）

3. 内置分页/带有总数的结果/一堆其他小细节。

4. 与Hibernate没有明确的联系（尽管我个人并不十分在意；我不会突然放弃Hibernate并明天使用EclipseLink）；有可用的Hibernate和通用JPA实现。

可以将过滤器添加到服务端的“搜索”中；那也是指定实体类的时候。唯一缺少的是，如果指定了无效的属性名称，则客户端会快速失败，这可以通过编写我自己的ISearch
/ IMutableSearch实现来解决，但我还没有解决。