Hibernate разница между Session и EntityManager

Hibernate появился в далеком 2001 году. Тогда JPA еще не было. JPA появилось во многом стараниями HIBERNATE и только в 2006. К этому времени у HIBERNATE был большой наработанный функционал, а в для первой версии JPA удалось согласовать (с другими фирмами-разработчиками аналогичных продуктов) только часть этого объема функционала. Поэтому, разработчики HIBERNATE сознательно (чтобы не было путанницы) пошли на то, чтобы в HIBERNATE имелось два пути работы - старый путь - нативный HIBERNATE (через интерфейс Session) и новый путь JPA (через интерфейс EntityManager). Интерфейсы разные, методы как правило имеют одинаковые названия. Различия есть и в других элементах - например, HIBERNATE конфигурируется файлом hibernate.cfg.xml, основанном на dtd, а JPA - persistence.xml, основанном на xsd, кроме того, во многоих областях приняты различные правила по-умолчанию. При этом, функциональность нативного HIBERNATE значительно больше, чем у JPA. И вообще, HIBERNATE не делал две различные реализации - одну для Session, а другую для EntityManager. Реализация EntityManager является оберткой (wrap) реализации Session. Класс SessionImpl реализует интерфейс Session, а Session расширяет интерфейс EntityManager. Если Вы выбираете путь JPA, то всегда имеете возможность быстро перейти, на другие реализации JPA- EclipseLink, OpenJPA, DataNucleus (и узнаете насколько они совместимы). Такая возможность может показаться единственным преимущество EntityManager перед Session, при существенно меньшем объеме функциональности. При желании, можно работая с EntityManager дотянуться через unwrap до интерфейса Session и воспользоваться его функционалом (ведь реализация у этих интерфейсов единая), но тогда при переходе на другие реализации такие места нужно будет переписывать особо. Такая техника, рекомендуется разработчиками HIBERNATE, хотя на мой взгляд это немного из цирка. Но главное, что разработчики HIBERNATE подают его (HIBERNATE) во-первых как реализацию JPA и только во-вторых вспоминают о дополнительных возможностях Session. В путевых картах 6 и 7 версии HIBERNATE, фактически говорится о том, что JPA будет вбирать в себя самое лучшее, а остальное в HIBERNATE будет как бы deprecated. В последних версиях пятого HIBERNATE, например, у Session стал deprecated createCriteria и эта часть перенесена в JPA.

Всё зависит от того, насколько сильно проект привязан к Hibernate. Если проект не использует непосредственно API Hibernate или, по крайней мере, может не использовать эти API, то можно использовать EntityManager и JPA.

С одной стороны это даёт возможность в процессе разработки заменить Hibernate на другую реализацию JPA, но с другой - а насколько вероятно возникновение ситуации, когда понадобится замена Hibernate? По-моему в первую очередь надо ориентироваться на удобство использования и предпочтения личные и/или команды.

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