Уровень базы данных не ORM (Java)

Question

Я хочу написать код Java для работы с базой данных, независимо от того, какая база данных используется.Моя проблема в том, что это не будет связано с объектом.Есть некоторые вставки и запросы, но большинство из них нет.

Прямо сейчас мы используем Postgresql и чистый JDBC, но нам, возможно, придется заставить его работать с Oracle.

Может ли Hibernate (который я никогда не использовал) решить мою проблему, или я должен идтидля чего-то еще?

Answer 1

Я создал jOOQ именно для этого. jOOQ моделирует сам SQL как предметно-ориентированный язык в Java. Он охватывает использование стандартных и специфичных для поставщика функций, таких как встроенные функции, оконные функции, хранимые процедуры, иерархические запросы и т. Д. Когда это возможно, специфичные для поставщика функции из одной базы данных моделируются для других баз данных. Таким образом, большая часть сгенерированного jOOQ SQL совместима с любой из 13 поддерживаемых баз данных.

Смотрите также этот связанный вопрос здесь:

Платформы ORM, используемые только для вставки / запросов только приложений

Answer 2

Мне нравится ответ JPA @ unludo, но я решил добавить некоторые дополнительные детали.

Я бы порекомендовал изменить ваш код, чтобы использовать определенный вами интерфейс персистентности.

  public interface DataPersister {
     public void saveFoo(Foo foo);
     public void findFooById(int id);
     ...
  }

Ваша первая реализация интерфейса будет тогда использовать JDBC / Postgresql.Если вы хотите использовать JPA под крышками, тогда хорошо.Или, если вы хотите переключиться на какую-либо базу данных без SQL или даже на простые файлы, тогда все в порядке.

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

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

Answer 3

Стандарт для Java - JPA, и он очень мощный. Hibernate является отраслевым стандартом в качестве поставщика JPA.

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

Также легко писать тестовые классы. Как коллега однажды научил меня, модель - это самое важное, что у вас есть. Вы не хотите, чтобы это сломалось или у вас есть проблемы.

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

JPA поможет вам применить хорошие практики на работе. Это большая ценность.

Что касается ответа @hvgotcodes, да, вы должны быть осторожны со стоимостью, но вы также можете смешивать jdbc и jpa. Вот для чего Дао.

Answer 4

Проблемы с Hibernate в том, что вам нужно моделировать вашу реляционную базу данных, как объектную модель.Иногда это затрудняет работу с существующей базой данных.Так что это зависит от вашей реляционной базы данных.

Другая структура (не JPA) - это Ibatis.Попробуйте взглянуть на эту структуру.

Answer 5

Проблема с написанием собственного sql заключается в том, что вам нужно вручную оптимизировать его для вашей СУБД. Некоторые РСУБД поддерживают различные конструкции SQL.

Таким образом, вам необходимо сбалансировать это с накладными расходами на переключение на решение на основе ORM. Или убедитесь, что sql соответствует 100% -ому стандарту, поэтому вы не используете конструкции, которые работают в одном решении СУБД, а не в другом.

В вашей конкретной ситуации, вероятно, будет проще просто исправить свой sql, чем переделать весь слой постоянства, чтобы использовать ORM. Иногда лучший инструмент - тот, который ты знаешь. Если ваше текущее приложение не имеет краткого уровня модели, переключение на ORM потребует много работы. Конечно, вы можете использовать hibernate и просто использовать прямые SQL-запросы, но какой смысл, если вы не собираетесь моделировать свои данные.

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