Так уж ли хорош подход JPA?
=============================

 Добрый день.  
  

Сразу оговорюсь, никого не хочу задеть и не хочу обидеть. Недавно начал погружаться в Java EE и хочу разобраться.  
  

Сейчас разбираюсь с JPA. Как мне показалось, этот метод дает больше проблем, чем преимуществ. Когда-то давно, когда я еще не знал о Java EE, я реализовал некое подобие JPA. Я помню вечные муки с зависимостями. В одном месте подгрузка нужна, в другом нет, в третьем не понятно сразу. Часть полей нужна, часть нет и даже ленивая подгрузка не спасала.  

Для изучения EE я купил книгу [Изучаем Java EE 7, Гонсалвес Энтони](https://books.google.ru/books?id=gEJJCAAAQBAJ&hl=ru&source=gbs_slider_cls_metadata_7_mylibrary&redir_esc=y). Я был в восторге от CDI, в EJB не "въехал" (отдельным вопросом спрошу), но больше всего меня разочаровал JPA тем, что не дал железобетонных решений проблем, а лишь создал впечатление костыль-обертки вокруг JDBC.  
  

Попробуем сравнить. Для начала плюсы:  

1) Конечно, в коде удобнее использовать объекты, а не, например, Map-ы (хотя с выводом типов и метамоделью для последних можно еще по сравнивать).  

2) База-независимость. Это, конечно, же спорный вопрос. Я сильно не вникал, но боюсь, к примеру, полнотекстовый индекс и поиск по нему не будет база-независимым. Если вообще возможен будет. Поправьте, если я где-то не прав.  

3) Отсутствие SQL в коде. Конечно, кто-то скажет, что это дело вкуса, но многие меня поддержат.  

4) Опыт работы с JPA в резюме.  

Прошу читателей пополнить список.  
  

Теперь проблемы, которые я вижу.  

1) Возможны неоптимальные запросы к базе. Я с этим не сталкивался, прочел в какой-то статье про опыт. Пожалуй, это самый проблемный вопрос.  

2) Проблемы с зависимыми строками, которые я описал выше.  

3) В отчетах всё-равно, скорее всего придется "опуститься" до sql.  

4) Некая ограниченность. Чтобы сделать, к примеру, someField += 1 в базе для нескольких строк придется нелегко. А что взамен?  

Прошу читателей пополнить и этот список.  
  

Буду благодарен за реальный долговременный опыт работы с JPA, толковые книги. Такие в которых описывается не техническая работа, а методика применения (в каких случаях какие методы применять).  

# По словам "опыт работы с JPA" находятся вакансии:)  
  

Спасибо. 

 JPA - это же спецификация, а описанные вами проблемы, я думаю нужно рассматривать на конкретной ее реализации. 

 В некоторых случаях JPA вполне подходит, там, где не нужно строить сложных запросов и где не требуется выжимать из запросов всю возможную производительность, например, какая-нибудь не очень сложная админка. И, наоборот, если требуется выжать из БД всё, что возможно - тут без sql не обойтись, и прикручивать JPA может не дать никаких преимуществ в простоте доступа к БД, а лишь создаст путаницу и сложное переплетение JPA и нативных запросов.