How to layout Java EE projects using common JPA entities?

微笑、不失礼 提交于 2019-12-04 11:46:07

1) Does the project, containing the common entities, has a persistence.xml file? If so, how does it differ from the one in the other projects?

Yes. The main difference is that the persistence.xml in the model project should define all entities and that the persistence.xml in the web projects should just reference the model project JAR file. Otherwise you keep duplicating entites in persistence.xml files.

Another possible difference is that the one in model project should use a resource local transaction type so that unit testing from within the project (e.g. using a main() method) is done very easily. The ones in web projects should of course use a datasource by e.g. JTA.


2) How exactly are the commonly used entities referenced in the two projects? Do I use the <jar-file> tag in their persistence.xml for reference? And if so, would "lib/MyCommon.jar" be the right way to use, if MyCommin.jar is located in WEB-INF/lib?

Yes and No. The <jar-file> is the right way, but you have a typo in the filename and the folder should be omitted. The lib folder is usually only used when you've an EAR and the JAR is included in EAR's lib folder.

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

3) Does it make any difference if the application is deployed as a WAR or an exploded archive in JBoss 6?

No. Properly designed Java API's don't rely on the local disk file system, but just on the classpath. It makes for the classpath no difference if the WAR is expanded or not.


4) When deployed within eclipse via addition to server runtime and publish, is there anything different from deploying outside eclipse?

Technically, yes. Functionally, no.


5) Is the described way putting common entities in a separate project, creating a JAR and use that JAR in the other project a sensible way to handle the problem of sharing common entity classes or is there a better way?

It makes definitely sense. You don't want to repeat yourself.

From my experience, each jar must have a persistence xml, and that means that each EntityManager will be bound to one persistence xml. This means that in order to have transactions that involve entities from different jars, you'll need to use a JTA provider. One option to avoid what I mentioned above, is to have some Ant or Maven task to assemble classes from different jars into a new jar which contains the final persistence xml.

Having said that, in the projects where I used a shared project to put my entities, I had to end up putting all my entities (for the reason above).

I now think that the best way to do this, is to break the system into vertical modules, where each module manages it's own entities and can reference entities in other modules just by id. This is the best way I've found to build SOA applications and normal apps too. The reason to do this, is that it reduces the coupling drastically between the entities and modules too.

A few questions to ask yourself

  • Do you really want 2 different applications to update the same database tables?
  • What are you going to do if you need to update one application but the other one should remain the same?
  • Do the entities expose more information that the application really needs?
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!