Зачем использовать JPA вместо прямого написания SQL-запроса на Java файле (т.е. Непосредственно в JDBC)?

Я читал несколько статей о том, что такое JPA (Java Persistent API) и какой поставщик поддерживает его (DataNucleus, JBoss Hibernate и т.д.)

У меня нет опыта работы с ORM (реляционное сопоставление объектов).

Что я сделал до сих пор, так это написать свои собственные классы базы данных, используя DTO и DAO. До сих пор я доволен тем, что у меня есть, но хотел бы знать , почему люди используют JPA над Java файлом, который содержит SQL.

Мне кажется, что писать класс DAO будет нормально, как показано ниже.

public class DAOUsers {
     public void insertNewUser(DTO DtoUser) {
           String query = "INSERT INTO users(username, address) " +
                          "VALUES(DtoUser.username , DtoUser.address)";
           Executor.run(query);
     }

}

Я узнал, что JPA использует язык JPQL, Java persistent query и работает против объекта entity а не напрямую с таблицами db.

Мое понимание (исправьте меня, если я ошибаюсь), что объект объекта здесь такой же, как мой объект DTO (вроде как bean?)

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

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

Ответ 1

Зачем использовать JPA вместо прямого запись SQL-запроса в файл Java (т. непосредственно в JDBC)?

Некоторые проекты требуют от инженеров больше сосредоточиться на объектной модели, а не на реальных SQL-запросах, используемых для доступа к хранилищам данных. На самом деле вопрос можно интерпретировать как

Почему нужно использовать структуру ORM?

который может иметь разные ответы в разных контекстах.

Большинство проектов могут извлечь выгоду из наличия модели домена, при этом персистентность является второй проблемой. С JPA (реализациями) или большинством других инфраструктур ORM возможно иметь все сущности, т.е. Таблицы в вашей базе данных, смоделированные как классы в Java. Кроме того, также возможно встроить поведение в эти классы и, следовательно, достичь модели поведенческой богатости. Объекты этой модели могут иметь несколько целей, включая назначение замены DTO для транспортировки данных по уровням.

Тем не менее, существуют места, где рамки ORM могут не соответствовать прямой проблеме, особенно когда модель данных уже установлена ​​или когда вы работаете с устаревшими системами, где сопоставление таблиц базы данных с Java-классами является нестандартным, тривиальные упражнения. И в некоторых случаях, если нужно полностью настроить вывод из SQL, сгенерированного инфраструктурой ORM, тогда рамки ORM обычно плохо подходят.

Вопросы, относящиеся

Ответ 2

Что действительно выгодно JPA дает возможность писать чистый SQL в моем файле?

Вот некоторые из преимуществ:

  • JPA позволяет избежать написания DDL в конкретном диалоговом окне SQL. Вместо этого вы пишете "сопоставления" в XML или с помощью аннотаций Java.

  • JPA позволяет избежать написания DML в конкретном диалекте базы данных SQL.

  • JPA позволяет загружать и сохранять объекты Java и графики без какого-либо языка DML вообще.

  • Когда вам нужно выполнять запросы, JPQL позволяет вам выражать запросы в терминах сущностей Java, а не (собственных) таблиц и столбцов SQL.

Вообще говоря, JPA проще, чище и менее трудоемко, чем JDBC + SQL + рукописные сопоставления. Чем сложнее ваша модель данных, тем она более полезна.

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

JPA, вероятно, также не для вас, если вы гораздо удобнее манипулировать Java, JDBC и SQL в одном приложении, чем разрешать ORM работать с беспорядочными деталями. (Но если это так, вы, вероятно, в меньшинстве...)

Ответ 3

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

Во-первых, @vineet предлагает "сущности могут иметь несколько целей"... которые я видел в процессе производства, и, я бы сказал, поощряется ORM. Так много для сплоченности и единственной ответственности. По моему опыту, добавление поведения к объектам базы данных вызывает проблемы. Я знаю это, потому что я это сделал, и жалел об этом.

Во-вторых, есть простые альтернативы сложности JPA, которые предоставляют возможность использовать классы с РСУБД без всякой тяжести (и проблем с производительностью), вызванных несоответствием, которое ORM пытается (безуспешно) решить. Мы используем инструменты сопоставления реляционного класса, не относящиеся к JPA, в течение десятилетия в приложении с более чем 1000 таблицами, и мы просто не видим, как JPA улучшает более прямой доступ к базе данных. JPA скрывает мощь базы данных при добавлении служебных данных (в виде аннотаций и JQL) в модель класса... не должно ли работать другой способ?

@water предлагает множество вещей, которые истинны в теории, но непрактичны в реальности. Например, три раза меняя базы данных бэкэнда, я могу заверить читателей, что нет такой вещи, как несколько настроек конфигурации, и все готово. Я бы посоветовал, если вы тратите много времени на поддержание уровня персистентности, ваша модель базы данных развивается, и вы будете делать то же или более работу в JPA. В частности, когда нетривиальные запросы в JPA требуют использования JQL!

Почти все притворяются, что разработчикам JPA не нужно знать SQL. То, что я видел на практике, состоит в том, что теперь нам нужно изучить SQL и JQL. По-видимому, нам не нужно делать DDL - но в любом нетривиальном приложении, конечно, вам нужно знать DDL. Hibernate даже не рекомендует использовать автоматическую генерацию DDL. По-видимому, нам не нужно делать DML, за исключением случаев, когда мы обращаемся к Native Query, который, конечно, не переносимый, разбивает кеш и имеет все те же проблемы, что и JDBC...

В конечном счете, в правильно структурированном приложении, в котором модель домена не зависит от бизнес-логики, JPA практически не обеспечивает функциональности для того, что я считаю очень высокой кривой обучения, потому что модель домена на самом деле очень легко построить. Я бы не использовал JDBC напрямую, но что-то вроде Apache DBUtils обеспечивает простой уровень над JDBC, который отображает строки в объекты, и с небольшим усилием может обеспечить большинство преимуществ JPA ни с одной из скрытых и ни с одной из накладных расходов.

Я разрабатываю приложения баз данных Java с JDBC 1.0, используя множество библиотек (и iODBC и ESQL до JDBC), и только по соображениям производительности, я закончил с JPA. Но даже если производительность была лучше, кривая обучения и неполные абстракции дают мне серьезную паузу. JPA сложна и пытается скрыть детали, которые, на мой взгляд, разработчикам действительно нужно заботиться. В качестве примера мы недавно увидели, что в команде удалялось 250 команд удаления, если этого было достаточно. JPA, по своей природе, делает такую ​​ошибку легкой.

Я не выступаю за JDBC, я просто выступаю против JPA. Разработчики, которые не работают или не могут работать в SQL, вероятно, не должны писать реляционные приложения - не больше, чем такие разработчики, как я, которые не могли бы выполнять матричную алгебру, чтобы сохранить мою жизнь, должны писать 3D-игры. Разработчики, которые используют SQL для жизни, должны быть в ужасе от искаженного SQL, который спящий, для одного, отправляет серверу, чтобы избежать круговых поездок, которые не должны быть необходимы в первую очередь.

Ответ 4

Если все сделано правильно, вы можете сопоставить SQL-запросы непосредственно с java-объектами с реализациями JPA, такими как спящий режим. Недавно я сделал проект, в котором у меня было POJO и 3 или 4 аннотации и немного кода установки, чтобы взять хранимую процедуру и сопоставить ее непосредственно со списком объектов (типа класса POJO). Это для меня часть власти JPA.

Если вы используете его, как если бы вы прямо работали над SQL + JDBC, то я не знаю никаких преимуществ.

Здесь есть достойная статья о преимуществах JPA.

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

Ответ 5

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

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

В стойке, == > больше не требуется API JDBC для набора результатов или обработки данных. == > Это помогает уменьшить количество строк кода, & && & & & == > Он абстрагирует наше приложение от базовой базы данных SQL и SQL-диалекта. Для переключения в другую базу данных SQL требуется несколько изменений в конфигурационном файле Hibernate (пишите один раз/в любом месте).

Ответ 6

Кроме того, поскольку вы знаете лозунг Java: "Пишите один раз, бегите везде"

Также с JPQL вы можете выполнять ваши запросы JPQL в каждой базе данных (DB2, Oracle и т.д.)

Ответ 7

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