Как макетировать проекты Java EE, используя общие сущности JPA? - PullRequest
Новая
       61

Как макетировать проекты Java EE, используя общие сущности JPA?

3 голосов
/ 13 июля 2011

У меня есть два проекта затмения Java EE 6, упакованные в WAR-файл с использованием maven 3. Теперь они должны совместно использовать объекты JPA в третьем проекте, поскольку оба они используют одну и ту же базу данных.

При проведении исследования моего вопроса я обнаружил несколько подсказок, в которых упоминается, например, ссылка в файле persistence.xml на обычный jar-файл, но мне не удалось заставить его работать. Так специально спросил:

1) Есть ли в проекте, содержащем общие сущности, файл persistence.xml? Если да, то чем он отличается от других проектов?

2) Как именно на общеупотребительные объекты ссылаются в двух проектах? Использую ли я тег в их файле persistence.xml для справки? И если да, то будет ли "lib / MyCommon.jar" правильным способом использования, если MyCommin.jar находится в WEB-INF / lib?

3) Имеет ли какое-либо значение, если приложение развернуто как WAR или разнесенный архив в JBoss 6?

4) При развертывании в Eclipse с добавлением к среде выполнения сервера и публикации, есть ли что-то отличное от развертывания внешнего Eclipse?

5) Является ли описанный способ помещения общих сущностей в отдельный проект, создания JAR и использования этого JAR в другом проекте разумным способом решения проблемы совместного использования классов общих сущностей или есть лучший способ?

Ответы [ 2 ]

7 голосов
/ 13 июля 2011

1) Есть ли в проекте, содержащем общие объекты, файл persistence.xml? Если да, то чем он отличается от других проектов?

Да. Основное отличие состоит в том, что persistence.xml в модельном проекте должен определять все сущности и что persistence.xml в веб-проектах должен просто ссылаться на файл JAR модельного проекта. В противном случае вы продолжаете дублировать энтиты в persistence.xml файлах.

Другое возможное отличие состоит в том, что в модели проекта должен использоваться локальный тип транзакции ресурса, так что модульное тестирование внутри проекта (например, с использованием метода main()) выполняется очень легко. Те, кто в веб-проектах, должны, конечно, использовать источник данных, например, JTA.

2) Как именно на общеупотребительные объекты ссылаются в двух проектах? Могу ли я использовать тег <jar-file> в их файле persistence.xml для справки? И если да, то будет ли правильным использовать «lib / MyCommon.jar», если MyCommin.jar находится в WEB-INF / lib?

Да и нет. <jar-file> - правильный путь, но у вас есть опечатка в имени файла, и папка должна быть пропущена. Папка lib обычно используется только в том случае, если у вас EAR, а JAR включен в папку EAR lib. 

<jar-file>MyCommon.jar</jar-file>

3) Имеет ли какое-либо значение, если приложение развернуто как WAR или разорванный архив в JBoss 6?

Нет. Правильно спроектированные Java API не полагаются на файловую систему локального диска, а только на путь к классам Для пути к классам не имеет значения, расширена ли WAR или нет.

4) При развертывании в Eclipse через добавление к среде выполнения сервера и публикации, есть ли что-то отличное от развертывания внешнего Eclipse?

Технически, да. Функционально №.

5) Является ли описанный способ помещения общих сущностей в отдельный проект, создания JAR и использования этого JAR в другом проекте разумным способом решения проблемы совместного использования классов общих сущностей или есть лучший способ?

Это определенно имеет смысл. Вы не хотите повторяться .

1 голос
/ 13 июля 2011

По моему опыту, каждая банка должна иметь постоянный XML, и это означает, что каждый EntityManager будет связан с одним постоянным XML.Это означает, что для того, чтобы иметь транзакции, в которых участвуют объекты из разных jar-файлов, вам необходимо использовать JTA-провайдера.Один из способов избежать того, что я упомянул выше, - это выполнить задачу Ant или Maven, чтобы собрать классы из разных jar-файлов в новый jar-файл, содержащий окончательное постоянство xml.

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

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

Несколько вопросов, которые вы себе задаете

  • Вы действительно хотите обновить 2 разных приложения?те же таблицы базы данных?
  • Что вы собираетесь делать, если вам нужно обновить одно приложение, но другое должно остаться прежним?
  • Предоставляют ли сущности больше информации, которая действительно нужна приложению?
...