Возможно ли и рекомендуется ли поддерживать две реализации JPA?

Question

У нас есть приложение, которое мы разрабатываем, и мы рассматриваем возможность поддержки двух разных реализаций JPA.

На данный момент мы используем openjpa и имеем довольно хорошо протестированный код.

Я поменял местами toplink, запустил тесты и обнаружил кучу сбоев.

Вы могли бы подумать, что, поскольку JPA является стандартом, не должно быть никаких отличий!

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

Итак, во-первых, правда ли, что между реализацией и сервером существует взаимно-однозначное сопоставление. например, я могу использовать toplink на WAS или openjpa на Glassfish?

Второй вопрос, прежде чем я продолжу исследовать различные сбои, заключается в том, является ли спецификация JPA настолько широкой, чтобы сделать поддержку двух реализаций непрактичной? Стоит ли пытаться заставить код работать с обоими?

Answer 1

Нет, это не так - на серверах приложений не применяются никакие реализации JPA, и вы должны иметь возможность использовать OpenJPA с различными серверами приложений. Так же, как вы можете использовать Hibernate везде, где вы можете использовать любую другую реализацию JPA. Да, у вас могут возникнуть конфликты из-за банок и устранение неполадок, которые нужно решить, прежде чем все станет правильно ...

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

Answer 2

Мы заметили то же самое, когда использовали TopLink Essentials и перешли на EclipseLink. Наш код сломался во многих местах, хотя EclipseLink основан на одной и той же кодовой базе!

Мы обнаружили, что большинство случаев было связано с тем, что TopLink Essentials не полностью соответствовал спецификации JPA (например, собственные запросы возвращают список векторов и т. Д.). Я ожидаю, что переносимость между EclipseLink и Hibernate будет лучше, но, вероятно, не идеальна.

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

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

Answer 3

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

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

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