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

Question

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

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

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

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

У меня были обсуждения с партнером, и я считаю, что он прав, когда говорит, что для поддержания низкого уровня связи класс 'Listing' (опять же, верхняя часть иерархии данных в данных) НЕ ДОЛЖЕНзнать о поисковой системе и НЕ иметь в ней статических функций, которые выполняют поиск в поисковой системе.Он заявил, что шаблон проектирования «Цепочка ответственности» может быть подходящим способом, позволяющим 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

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

Насколько я понимаю, у вас есть две разные системы, и вы хотите отправить один и тот же запрос обеим.Вам необходимо знать, каковы отношения между этими двумя системами:

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

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