Что такое хороший шаблон проектирования для моделирования API для параллельной поисковой системы и базы данных?

Question

(это в проекте Java)

Я использую поисковую систему параллельно с реляционной базой данных. Основным объектом, представляющим интерес, является «листинг». Он имеет приблизительно 5 других объектов в структуре стиля композиции. Один - это местоположение, другое - сложное определение времени и даты.

Из моего опыта, а также из исследования, поиск выполняется быстрее на Solr, Lucene, Elastic SEarch, чем любая база данных с добавленными полными текстовыми и географическими индексами. Поэтому я хочу использовать поисковую систему для данных, находящихся в базе данных. Кроме того, поисковая система будет содержать более подробные записи по времени, чем база данных, более конкретные и формальные.

Итак, в отношении шаблона проектирования: Цель состоит в том, чтобы CRUD происходил из API как для содержимого базы данных на сущности, так и во все время и для географических перестановок, созданных в индексе поисковой системы.

У меня были дискуссии с партнером, и я считаю, что он прав, когда он говорит Чтобы поддерживать связь низкой, класс «Листинг» (опять же, вершина иерархии данных в данных) НЕ должен знать о поисковой системе и НЕ добавили к ней статические функции, которые выполняют поиск в поисковой системе. Он заявил, что шаблон дизайна «Цепь ответственности» может быть подходящим способом, позволяющим CRUD API работать как в базе данных, так и в содержимом поисковой системы. Я читал, что это неправильно.

Я смотрел на http://sourcemaking.com/design_patterns, и я думаю, что шаблон фасада, http://sourcemaking.com/design_patterns/facade, может быть лучше. Но я хотел бы услышать другие мнения.

Заранее спасибо.

PS. Я разрабатываю osem-слой (http://en.wikipedia.org/wiki/Compass_Project), который можно вводить в Spring IOC. Этот слой выполнен для ElasticSearch. На данный момент он не поддерживает транзакции или внешние ключи (и, возможно, никогда этого не сделает). Но у него будут аннотации, чтобы развить их позже. Вы можете посмотреть на это. Он находится в https://github.com/kwince/osemManager. В настоящее время существуют две ветви. Я выберу, с кем слияние на следующей неделе.

Answer 1

Фасад-паттерн более подходит для скрытия некоторой сложной подсистемы за относительно простым интерфейсом.

Из того, что я могу понять, у вас есть две разные системы, и вы хотите отправить один и тот же запрос. Вы должны знать, что отношения между этими 2 системами:

• Если есть какая-то форма предпочтения одной системы над другой, вы бы использовать цепочку ответственности: вы бы отправить запрос, если первая система может справиться с этим, вы получите результат, если нет, запрос переходит к следующей системе в цепочке и так далее.
• Если есть какая-то форма увеличения или улучшения результата из одной системы по результатам из другого, вы должны использовать Decorator, поэтому сначала запрос поступает во «внешнюю» систему, он обращается к «внутренней» системе, получает некоторые результаты, затем украшает их своими собственными данными и возвращает оформленные результаты;
• Если у вас только две независимые системы, которые вы хотите запросить параллельно, используйте «просто сделать это» pattern =) Используйте некоторые примитивы parralel из своей структуры, отправьте 2 запроса, дождитесь обоих результатов, отправьте их в функцию слияния ,

Надеюсь, это поможет.