Хотя это старый вопрос, я чувствую, что он заслуживает нового ответа.Я недавно внедрил JPA, я использовал его в течение нескольких лет, и хотя у меня были моменты впечатления от простоты установки нового приложения, я совершенно не впечатлилсяс производительностью, сложностью и кривой обучения, необходимой для правильного выполнения JPA.Ответы в этой теме на самом деле подтверждают мою позицию.
Во-первых, @vineet предлагает "сущности могут иметь несколько целей" ... что я видел в работе, и я бы сказал, что это поощряется ORM.Так много для сплоченности и единого принципала ответственности.По моему опыту, добавление поведения к объектам базы данных вызывает проблемы.Я знаю это, потому что я сделал это и жил, чтобы сожалеть об этом.
Во-вторых, существуют простые альтернативы сложности JPA, которые предоставляют возможность использовать классы с RDBMS без всякой тяжести (и производительности).проблемы), вызванные несоответствием, которое ORM пытается (безуспешно) решить.Мы использовали инструменты отображения реляционных классов не JPA в течение десятилетия в приложении с более чем 1000 таблицами, и мы просто не видим, как JPA является улучшением по сравнению с более прямым доступом к базе данных.JPA скрывает мощь базы данных, добавляя дополнительные данные (в форме аннотаций и JQL) к модели классов ... разве это не должно работать по-другому?
@ water предлагает множество вещей, которые верны втеория, но неосуществимая в реальности.Например, переключив базы данных три раза, я могу заверить читателей, что нет такой вещи, как несколько настроек конфигурации, и все готово.Я бы посоветовал, если вы тратите много времени на поддержание своего уровня персистентности, ваша модель базы данных развивается, и вы будете выполнять ту же или более работу в JPA.Особенно, когда нетривиальные запросы в JPA требуют использования JQL!
Почти все делают вид, что разработчикам JPA не нужно знать SQL.Что я видел на практике, так это то, что теперь мы должны изучать SQL и JQL.Очевидно, нам не нужно делать DDL - но в любом нетривиальном приложении , конечно, , вам нужно знать DDL.Hibernate даже не рекомендует использовать автоматическую генерацию DDL.По-видимому, нам не нужно делать DML, за исключением случаев, когда мы обращаемся к собственному запросу, который, конечно, непереносим, разбивает кэш и имеет все те же проблемы, что и JDBC ...
В конечном счетеВ правильно структурированном приложении, в котором модель предметной области не зависит от бизнес-логики, JPA предоставляет мало функциональных возможностей для того, что я считаю очень высокой степенью обучения - потому что модель предметной области на самом деле очень легко построить.Я бы не стал использовать JDBC напрямую, но что-то вроде Apache DBUtils предоставляет простой уровень над JDBC, который отображает строки в объекты, и, приложив немного усилий, может обеспечить большинство преимуществ JPA без каких-либо скрытий и никаких накладных расходов.
Я разрабатывал приложения баз данных Java начиная с JDBC 1.0, используя различные библиотеки (и iODBC и ESQL до JDBC), и только по соображениям производительности я закончил с JPA.Но даже если бы производительность была лучше, кривая обучения и неполные абстракции дают мне серьезную паузу.JPA сложен и пытается скрыть детали, которые, на мой взгляд, разработчики действительно должны заботиться.В качестве примера, мы недавно увидели спящий выпуск 250 команд удаления в базу данных, когда их будет достаточно.JPA по своей природе облегчает подобные ошибки.
Я не защищаю JDBC, я просто выступаю против JPA.Разработчики, которые не работают или не могут работать в SQL, вероятно, не должны писать реляционные приложения - так же, как разработчики, подобные мне, которые не могут заниматься матричной алгеброй, чтобы спасти мою жизнь, должны писать 3D-игры.Разработчики, которые используют SQL для жизни, должны быть в ужасе от искаженного SQL, который, например, отправляет в спящий режим на сервер, чтобы избежать циклических переходов, которые не должны быть в первую очередь необходимыми.