Spring Data Specification: наложение фронтенд-фильтров на репозитории spring data

Коллеги, добрый день. Во многих проектах для работы с данными на бекенде используется Spring Data со всеми плюшками использования декларативного подхода описания запросов к данным на основе интерфейсов. Также очень часто бекенду нужно быть очень универсальным, чтобы обрабатывать произвольные запросы от фронтенда.

Рассмотрим ситуацию: мы реализуем интернет-магазин. Со стороны UI пользователь имеет возможность осуществлять поиск товаров, задавания произвольное количество фильтров. Например, он может указать в качестве фильтров для поиска:

• Найти все книги с заданным названием.

• Найти все книги, у которых жанр - фантастика и имя автора начинается с “абв”.

• Найти все книги с обложкой желтого или красного цвета.

Со стороны бекенда сущности Книга, Жанр, Автор и Тег хранятся в разных таблицах и соединяются по foreign key. Для каждой сущности есть свой отдельный репозиторий и Entity.

Когда бекенд получает от фронтенда запрос на поиск, то необходимо преобразовать этот произвольный набор фильтров и в соответствии с ними выбрать:

• нужный репозиторий

• нужный метод в этом репозитории

• определить, нужно ли делать join, чтобы отфильтровать сущности по полю соединенной таблицы

Задача: на основе произвольных json-фильтров, приходящих с фронтенда формировать sql-запросы с условием по полям, указанным в фильтрах.

Более подробно про особенности интерфейса Specification описано в статье.

Если кратко, то Specification помогают наложить фронтенд-фильтры на репозитории spring data.

Объект фильтра, приходящего с фронтенда:

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class SearchCriteria implements Filter {
private final String type = "SEARCH";
/**
* Название поля по которому ищем (должно соответствовать названию поля в
таблице БД)
*/
@ApiModelProperty(value = "Название поля по которому ищем (должно
соответствовать названию поля в таблице БД)")
private String key;
/**
* Название таблицы, которую присоединяем (для вложенных полей, например,
пользователь author)
*/
@ApiModelProperty(value = "Название таблицы, которую присоединяем (для
вложенных полей, например, пользователь author)")
private String table;
/**
* Операция сравнения для фильтрации (EQ, GR, LO, IN)
*/
@ApiModelProperty(value = "Операция сравнения для фильтрации (EQ, GR, LO,
IN)")
private String operation;
/**
* Значение по которому ищем
*/
@ApiModelProperty(value = "Значение по которому ищем")
private Object value;
}

Поскольку поиск может осуществляться не по одному, а по нескольким полям сразу,

можно добавить фильтры для OR и AND, а также общий интерфейс для всех фильтров:

@JsonTypeInfo(
use = JsonTypeInfo.Id.NAME,
property = "type",
include = JsonTypeInfo.As.EXISTING_PROPERTY
)
@JsonSubTypes({
@JsonSubTypes.Type(value = OrFilter.class, name = "OR"),
@JsonSubTypes.Type(value = AndFilter.class, name = "AND"),
@JsonSubTypes.Type(value = SearchCriteria.class, name = "SEARCH")
})
public interface Filter {
}
@Data
public class AndFilter implements Filter {
private final String type = "AND";
/**
* Значение по которому ищем
*/
@ApiModelProperty(value = "Набор фильтров")
private List<Filter> value;
}
@Data
public class OrFilter implements Filter {
private final String type = "OR";
/**
* Значение по которому ищем
*/
@ApiModelProperty(value = "Набор фильтров")
private List<Filter> value;
}

После того, как фильтры были получены с фронтенда через контроллер, их необходимо передать в сервис, для того, чтобы сформировать объект Specification:

Specification<Workspace> specification = SpecificationCreator.create(filter);
Page<Workspace> results = workspaceRepository.findAll(specification,
pageable);

Преобразование filter в specification происходит в SpecificationCreator:

@UtilityClass
public class SpecificationCreator {
public Specification<Workspace> create(Filter filter) {
if (filter instanceof OrFilter) {
OrFilter orFilter = (OrFilter) filter;
List<Specification<Workspace>> specs =
createInnerSpecifications(orFilter.getValue());
return createOrSpecification(specs);
} else if (filter instanceof AndFilter) {
AndFilter andFilter = (AndFilter) filter;
List<Specification<Workspace>> specs =
createInnerSpecifications(andFilter.getValue());
return createAndSpecification(specs);
} else if (filter instanceof SearchCriteria) {
SearchCriteria searchCriteria = (SearchCriteria) filter;

return createSearhSpecification(searchCriteria);
}
return null;
}
private List<Specification<Workspace>>
createInnerSpecifications(List<Filter> value) {
List<Specification<Workspace>> specs = Lists.newArrayList();
if (value != null && !value.isEmpty()) {
value.forEach(f -> {
Specification<Workspace> specification = create(f);
specs.add(specification);
});
}
return specs;
}
private Specification<Workspace>
createAndSpecification(List<Specification<Workspace>> specs) {
Specification<Workspace> orSpecification =
Specification.where(specs.get(0));
for (int i = 1; i < specs.size(); i++) {
orSpecification = specs.get(i).or(orSpecification);
}
return orSpecification;
}
private Specification<Workspace>
createOrSpecification(List<Specification<Workspace>> specs) {
Specification<Workspace> andSpecification =
Specification.where(specs.get(0));
for (int i = 1; i < specs.size(); i++) {
andSpecification = specs.get(i).and(andSpecification);
}
return andSpecification;
}
private Specification<Workspace> createSearhSpecification(SearchCriteria
searchCriteria) {
return new WorkspaceSpecification(searchCriteria);
}
}

Спецификации соединяются друг с другом по условию AND с помощью метода and() и по условию OR с помощью метода or().

Отдельная спецификация представлена классом WorkspaceSpecification, который наследует Specification<E> : 

@RequiredArgsConstructor
public class WorkspaceSpecification implements Specification<Workspace> {
private final SearchCriteria criteria;
@Override
public Predicate toPredicate(Root<Workspace> root, CriteriaQuery<?> query,

CriteriaBuilder builder) {
Join<Object, Object> join = null;
if (criteria.getTable() != null) {
join = root.join(criteria.getTable());
}
if (Operation.GR.name()
.equalsIgnoreCase(criteria.getOperation())) {
return builder.greaterThanOrEqualTo(
root.<String> get(criteria.getKey()),
criteria.getValue().toString());
}
else if (Operation.LO.name()
.equalsIgnoreCase(criteria.getOperation())) {
return builder.lessThanOrEqualTo(
root.<String> get(criteria.getKey()),
criteria.getValue().toString());
}
else if (Operation.EQ.name()
.equalsIgnoreCase(criteria.getOperation())) {
if (criteria.getTable() != null) {
if (join.get(criteria.getKey()).getJavaType() == String.class) {
return builder.like(
builder.lower(join.get(criteria.getKey())),
"%" + criteria.getValue().toString().toLowerCase() + "%");
} else {
return builder.equal(join.get(criteria.getKey()),
criteria.getValue());
}
} else {
if (root.get(criteria.getKey()).getJavaType() == String.class) {
return builder.like(
builder.lower(root.get(criteria.getKey())),
"%" + criteria.getValue().toString().toLowerCase() + "%");
} else {
return builder.equal(root.get(criteria.getKey()),
criteria.getValue());
}
}
} else if (Operation.IN.name()
.equalsIgnoreCase(criteria.getOperation())) {
List<String> values =
Lists.newArrayList((List<String>)criteria.getValue());
if (criteria.getTable() != null) {
return join.get(criteria.getKey()).in(values);
} else {
return root.get(criteria.getKey()).in(values);
}
}
return null;
}
}

После того, как спецификация создана, ее можно использовать в репозитории. Для этого репозиторий наследуется от JpaSpecificationExecutor<Workspace>:

public interface WorkspaceRepository extends 
JpaRepository<Workspace,
String>, JpaSpecificationExecutor<Workspace> {
}

Подведем итоги

Преимущества использования Specification:

• универсальный подход при работе с ui-фильтрами

• упрощаются репозитории - нет необходимости вообще добавлять методы

• упрощается логика выбора нужного репозитория

Недостатки реализованного решения:

• сложно использовать параметризованный код с дженериками

• хотелось бы чтобы Entity и Repository генерировались автоматически

• нужен механизм для преобразования конкретного entity в универсальный response.

В заключение хочу поздравить всех с наступающим новым годом, а также приглашаю на бесплатный вебинар, где на конкретном примере, рассмотрим конфигурацию SpringBoot приложения, работающего одновременно с двумя разными реляционными базами данных, а так же использующего для этого SpringData-репозитории.

• Зарегистрироваться на бесплатный вебинар