Единый блок персистентности для модульного применения (JPA)

Question

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

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

Могу ли я сделать что-то подобное с JPA? Я легко могу сделать это с помощью .NET nHibernate (и, вероятно, с Hibernate), но я предпочитаю программировать против JPA, поскольку я нахожусь в среде Java EE.

Answer 1

Как ни странно, я сделал именно это, используя OSGi, Equinox и EclipseLink, но это не тривиально. По сути, пользовательский пакет берет все файлы persistence.xml из всех разрешенных пакетов, объединяет их в один файл persistence.xml, который используется для инициализации поставщика устойчивости EclipseLink. Кроме того, есть несколько пользовательских хуков, которые позволяют мне указать f.e. Варианты подключения отдельно для разработки и развертывания.

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

Преимущества: добавьте новый пакет, посмотрите, как он работает сразу, динамически, без перезапуска контейнера.

Answer 2

Я также изучаю, как сделать JPA модульным способом (в модульной системе Netbeans или в контейнере OSGI).

Одна вещь, о которой вы должны знать, это то, что если вам нужно построить центральныйБольшая EntityManagerFactory (от центрального модуля персистентности), чем у вас могут быть некоторые проблемы, если ваше приложение велико:

• Если модуль персистентности должен реагировать на события запуска / завершения работы модуля, ему нужныперестроить центральный EntityManagerFactory, когда модуль добавлен или удален.Если приложение большое (много классов), перестроение EntityManagerFactory будет медленным и дорогостоящим.

• Приложению не требуется хранить ссылки на EntityManagerFactory, поскольку при добавлении / удалении модуля старый устаревает.Приложение должно работать с очень недолгим EntityManager и всегда получать EntityManagerFactory.

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

Dynamic-JPA (http://www.dynamicjava.org/projects/dynamic-jpa) может помочь, если выработа в контейнере OSGI.