1

我所需要的只是为我所有的存储库提供一个通用的搜索/查找方法。像这样的东西：

public interface BaseRepository<T, ID extends Serializable>
    extends PagingAndSortingRepository<T, ID> {

    Iterable<T> search(SearchParameters sp);

}

其中SearchParameters对象表示每个属性的一组值，并且可能是应用于它们的条件。

Jpa Criteria 可能是要走的路，但我真的很难找到适合我需要的东西。

4

1 回答 1

0

我使用了一种方向相同的方法，但我宁愿说它是一种动态方法而不是通用方法。它现在工作得很好，我们只需提供搜索实体即可自动生成所有所需的过滤器。我还认为标准 api 是要走的路，但过了一段时间，所有的副作用都变得太混乱了，我转身自己用参数创建查询字符串。

我创建了一个 entityscanner，它获取所有域实体并为每个所需的过滤器生成 filterdefinition 对象。该扫描仪采用实体并跟踪属性达到一定水平（以保持过滤器的数量）。我不能在这里给你代码，因为它属于客户，但我可以提供的方法。

我在过滤器定义中需要的是：entitytype、propertypath、propertytype、valuesexpression 以防我们呈现选项（想想 masterdata）、需要的连接（以避免多次连接同一个表）、打开/关闭括号。这是过滤器的定义。

然后你需要一个值对象来保存用户的当前配置：Inputvalue, operator (>=), brackets, filter link (and/or) 。

有了这个，我们可以渲染一个完全动态的过滤引擎，但有一些小的限制。即我还没有实现同一实体的父搜索。

您可以开始简单地为每个过滤器生成一个子查询。像： where id in (select ....) 和/或 id in (select ...) 如果实体的数量不是太高，这可以正常工作，但是如果行数过多，您会感觉到几个子查询的性能损失在域实体表中很高。然后，您潜入并找到一种方法来分离属性路径所需的连接，并且在查询创建器中，您仅在必要时才再次找出连接实体的方式。

正如所说。从简单开始。获取简单类型（如字符串）的第一级属性并创建您的查询引擎。通过遵循特定的实体连接来增强它，并且在您可以发疯并引入表达式获取选项以进行选择渲染或使用输入参数的转换服务等等之后。

于 2013-09-03T18:22:30.177 回答