Что такое элегантный способ выразить запрос с помощью поискового компонента?

Question

В нашем проекте у нас есть компонент, но мы также хотим выразить стандартные запросы CRUD для этого компонента.Мы хотим иметь возможность фильтровать определенные поля (диапазоны, равенства, исключения и т. Д.).Прямо сейчас мы думали использовать SearchBean, который представлял бы такой набор фильтров.Однако мы понимаем, что этот поисковый компонент практически идентичен нашему реальному компоненту, и нам трудно найти более элегантное решение.

Как можно решить эту проблему?Мы не ищем каких-либо конкретных решений.

Answer 1

Предполагая, что вы хотите обработать это на сервере приложений.Вы можете рассмотреть возможность использования коллекций гуавы

http://scaramoche.blogspot.com/2010/08/googles-guava-library-tutorial-part-4.html

или CollectionUtils

http://commons.apache.org/collections/apidocs/org/apache/commons/collections/CollectionUtils.html#filter%28java.util.Collection,%20org.apache.commons.collections.Predicate%29

и BeanPredicate от BeanUtils

http://commons.apache.org/beanutils/v1.8.2/apidocs/org/apache/commons/beanutils/BeanPredicate.html

Вам нужно будет реализовать классы Predicate для типа фильтров, которые вы хотите поддерживать.

Answer 2

Боюсь, этот вопрос слишком открыт, чтобы дать хороший ответ. Это действительно зависит от ваших целей. Кроме того, вы явно не упомянули, что используете базу данных (в отличие от поиска в памяти), но я предполагаю, что вы используете.

Ваш подход (findEntitiesLikeMe) звучит как приятный и простой подход.

Существует множество языков запросов (JPQL / SQL / и т. Д.), Которые вы можете реализовать (либо санацией запроса и передачей его на нижний уровень, либо непосредственным анализом запроса).

Если структура вашего сервера достаточно древовидная, вы можете использовать XPath и вернуть пространство объектов, соответствующее XPath.

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

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