Дао интерфейс для нескольких баз данных? - PullRequest
Новая
       7

Дао интерфейс для нескольких баз данных?

0 голосов
/ 10 ноября 2018

Существует шаблон создания DAO interface перед DAO implementation. Я погуглил преимущества этого паттерна, и одним из ярких моментов была поддержка нескольких баз данных.

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

Мой вопрос заключается в том, какие могут быть ситуации, когда нам может потребоваться поддержка нескольких механизмов баз данных, обслуживающих одни и те же данные? Кроме того, если возникнет такая необходимость, как REST endpoints будет поддерживать различные базы данных?

Будут ли они похожи, например, на /db1/courses/, /db2/courses? Поправьте меня, если я сделал неправильное предположение или утверждение в этом вопросе.

Ответы [ 3 ]

0 голосов
/ 12 ноября 2018

Я просто хотел добавить к этому свой ответ о начале разработки Spring. Это одна из вещей, которая поначалу не будет иметь смысла. Вы в конечном итоге спросите себя:

  • Будет только 1 база данных, так что не имеет смысла, зачем это делать?
  • Зачем мне определять интерфейс, когда будет только 1 реализация?

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

  • Spring Data - это альтернатива использованию диспетчера сущностей, при котором вы определяете только интерфейсы, а Spring фактически создает bean-компоненты, которые реализуют вашу функциональность репозитория.
  • Дизайн - обеспечение того, что вы определите интерфейс, поможет сохранить ваш репозиторий в репозитории.
  • Упрощенное моделирование - хотя, возможно, вы все еще можете сделать это в Spring без необходимости определять интерфейс, оно все же будет немного чище, если вы захотите заменить реализацию другой.

Но на самом деле это просто способ Spring, людям будет легче понять ваш код, если вы сделаете это.

0 голосов
/ 12 ноября 2018

Я загляну сюда, чтобы описать пример из реального мира.

Недавно мы хотели заменить большую производственную базу данных (Oracle) на другую (SQL Server).

Для разных областей базы данных у нас были разные интерфейсы и реализации DAO. Например, CustomerDAO, AccountsDAO и т. Д.

Для каждого взаимодействия (например, CustomerDAO) у нас была реализация (CustomerDAOImplOracle).

Для нас было относительно просто написать версии DAO для SQL Server (разумеется, синтаксис SQL и библиотеки jdbc были разными) и поменять их местами с минимальными изменениями в нашей бизнес-логике (сервисы, использующие DAO).

Итак, CustomerDAOImplOracle был переопределён в CustomerDAOImplSQLServer. И так далее ...

Что мы узнаем:

  1. Интерфейсы обеспечивают хорошую абстракцию и допускают несколько реализаций
  2. Уровень DAO позволяет нам «выключать» базу данных (или ее клиентские библиотеки) при необходимости
  3. Сокрытие деталей реализации базы данных от бизнес-логики уменьшает сцепление и сложность
0 голосов
/ 10 ноября 2018

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

Итак, это был поток.

  RestController --> Service --> DBService 
                                           --> DB1Repository --> Connect to DB1
                                           --> DB2Repository --> Connect to DB2

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

...