We have a team of 5 to 8 people and our project is using Hibernate (ORM) but we are facing some problems related to HBM files and there respective VOs (Value Objects). Actually we all are working on different modules and we all are creating HBM files and there respective VOs as per our module (so we have our HBM files and VOs specific to our module). If common table is used in more than one module then we have multiple HBM file and their VOs for that single table. So should we place all the HBM files anf VOs to a specific location or keep them module specific even if we have multiple HBMs and VOs. Please suggest the GOOD or BAD practice as well.
Thanks
From the query it seems each module has its own data access. If its not very complex, you can put all the data access in separate module. A project can have multiple modules but should have one place for data access.
As suggested, you can have a DAO module which is only doing to Data related operations.
Packages can be used to identify different DAO types.
The common DAO should be kept simple. Business Logic should not go in that. Logic should be handled at a higher level.
Other than that :-
Your project should be properly structured i.e. packages should be clearly defined.
module1/src/../com/../../bl
module2/src/../com/../../b0
dataacess/src/../com/../../bl
dataacess/src/../com/../../bo
Dependencies should be clearly extrapolated. If you have one DAO module then DAO should be independent. Other Modules should depend on DAO. If its java you can use maven to do this.
Finally its the choice we make. There will be lot of best practices. You should choose what suits best in your scenario. In the end it should be simple and manageable in future.
There should be a common project that will contain all DAO related stuff. Each module/project will include that commonDAO project in its classpath to perform hibernate and database related operations. This will overcome HBM files duplicacy and ease to maintain code.
Related
I'm doing a task where I should design a simple phonebook application divided into modules.
phonebook-api: jaxb classes generated from xsd file, interfaces for repository, DAO and service.
phonebook-server: it consists of implementations of repository, DAO and service. Also it has class for importing xml into database.
phonebook-web: this module has all of the configuration needed for repositories, services etc. Also it has configuration for database. It has a few xml files which are used to generate DBI classes used in DAO and sql scripts to create a simple table to store contacts in phonebook database (it has only one table). In addition, this module has a simple controller.
phonebook-client: simple MBeans application.
This is situation right now:
phonebook-api module depends on phonebook-web, because it needs these DBI classes for DAO interface
phonebook-server module depends on phonebook-api because it needs interfaces for repository, DAO, service. Also it depends on phonebook-web because of these generated DBI classes.
phonebook-web module depends on both of these modules because they are needed for configuration.
So, there are cyclic reference. Can you please help me with this design problem?
The answer is in your question. The problem is with the design. The key to your solution is assign distinct purposes to each module, separate concerns and avoid mutual dependencies.
Other options you can explore include
What seems like an anti-pattern here is that you have a dependency on a web module. This is unlikely to be ideal. You should avoid having module dependencies on units high up the stack. This is what I would try to change first: extract shared code from phonebook-web into one of the shared modules.
Make smaller modules. Maven doesn't have a problem with that.
If a depends on b for package c, and b depends on a for java package d, then you can extract packages c and d into a separate module on which both a and b have a dependency.
Review whether you really need the separate modules.
Maybe having phonebook-api, phonebook-server, and phonebook-web in separate modules isn't necessary after all. Unless you intend to reuse these modules in different applications, you may be better off using the single phonebook-web with all your current modules' code in it.
I am working on a project that will have entities persisted to a database using JPA. We will be using Maven as the project management framework. I am wondering if it would be possible to create one project for the POJOs and another for the persistence definitions and then "combine" the two into a single output that contains the POJOs and their persistence information.
Basically I am trying to separate the code that POJOs from the persistence definition. Because the POJOs may be reused by several different projects that may or may not need to persist them and may or may not want to change the persistence information. (Similar but not quite the same as Is it possible to build a JPA entity by extending a POJO?)
I have two ideas on how I might be able to do it. If I were to use the POJOs in a web application I could provide persistence.xml and map the classes in that project and just add a dependency to the project containing the POJOs. But if I wanted to create a single jar file containing the persistence information and the POJOs, I think I could use the shade plugin?
Is there any other way to essentially merge two maven projects into a single output and is this a reasonable thing to want to do?
If I remember correctly, then annotations do not have to be on the classpath if you're not using them. The annotated classes can still be loaded.
So my recommendation would be:
Stick with the JPA annotations, as this is the easiest way to define the mappings and tooling support is usually better.
Declare the JPA dependencies as optional and probably also as provided.
If you need to override the mappings defined by the annotations, it should be possible to do this using the persistence.xml, AFAIK (never tried).
I do appreciate the input. In the end, the solution for me was to create two projects. The first provided the definition of the POJOs without any JPA information. Yes there are some JPA related members such as id but I will address those. The second project contained the JPA metadata (orm and persistence XML files).
As for the members related to persistence (e.g. id) I could probably live with those in the model classes but using the suggestion in this post (Is it possible to build a JPA entity by extending a POJO?) I extended my POJO classes and declared id in the "entity" sub classes. This does require some consideration when defining the POJO in terms of access to members.
One thing to note, this solution runs into trouble when you have a class hierarchy (inheritance in your model). The classes in your "pure" model inherit from some common class. That class is then extended in the "persistence" model to provide the id and other persistence related members. Now if the persistent subclasses inherit from the classes in the "pure" model, they do not inherit the id and other persistent members.
There may be workarounds in different inheritance mapping such as table per concrete class.
I have two Java projects with same domain objects.First project is the administration of a webapp. And second project is the webapp.
I've chosen this approach in order to allow deployment of administration without downtime for my webapp.
So both projects use same database. I'm using spring-data and marking entities with #Entity.
My question is: is there any way to replicate domain objects in each project?
For example creating another maven module with the domain objects and mark as a dependency. (But in this case #Entity will still work?).
the way is just as you said it - create a maven module (usually called datamodel, infomodel or something along those lines) that contains all of your JPA classes (#Entity classes).
this model can either be a completely separate 3rd project (more work) or, more likely, pick one of the 2 projects as the "owner" of the module and the other project will simply list it as a dependency. in both cases you'll need to think about things like version compatibility (what happens when you update administration but not the webapp and the entities changed? who updates the database, how do you make sure the older code can still read/write it?)
as for working, JPA classes work just fine in their own jar.
Like you have raised is a good approximation, separating two different maven projects.
What you're trying to do is very similar to the structure of Broadleaf Commerce. It is a multi-module project using Maven and Spring, is open source, so you can look at how it is structured to see if it helps.
Here you have another guide of how to implement it step by step. Hope it helps.
It seams that you will need at least three modules.
1st - the domain module with the enitity annotated domain classes;
2nd - the application itself witch depends on the domain module;
3rd - the adm module witch also depends on the domain.
Now that you have a multi-module maven project you should have a 4th project formally listing the other three as its child modules.
P.s.: Resist to the temptation of creating separate git repositories and evolving the versions of the modules separately.(just an advice)
I am having some problems getting Hibernate and Spring up and running. I have a web server project which makes use of several other projects which have persistent entities in them. The problem I have is that I get a ClassNotFoundException for an entity class that is stored within another jar inside of WEB-INF/libs.
Do I need to have a persistence.xml for each jar that contains entity classes?
Please let me know if you need to see any configuration files.
Depending on your set up there are probably a number of different ways to solve this - and none them usually feel idea (IMO).
The essential problem is to do with ClassLoader isolation. There are rules as to what the files within a jar can access.
In your particular case, the easiest way to solve it is probably to put the persistence.xml within the parent web project. If you are not using persistence xml, you need to bootstrap hibernate/spring from the web project.
The parent web project should have access to all the libraries within its WEB-INF/lib whereas each of the jars in the libs folder may not have access to each other.
You could set up another persistence.xml in each jar but they would not be composited together into one persistence unit. You would need to use a different pu depending on which entity you wanted.
Is it possible to have a Seam project just for entities (src/main) and other projects access them ?
I have a situation that a organization has 6 projects accessing the same entities and i don't want to replicate them in each project. If it is possible, how can i do that ? where can i found documentation about it ?
thanks,
Cateno Viglio
Yes, it is very common way. Look at Richfaces photo album example where you have ejb module holding domain and used as dependency in web module. Of course you must remember adding empty file seam.properties to result jar file.
PS. This example is built by maven and uses ejb (entities and sessions beans). You can use seam-gen and POJO instead if you like.
Depends on what exactly you mean.
Yes, you can declare separate projects for your entity classes. I have about 50 projects roughly. Of those less than a handful are actually web applications packaged as WAR files. The rest are comprised up of utility projects, service projects, listeners, entities, and servlet filters.
Breaking the projects up this way has its advantages and disadvantages. Any time you make a change to a project, you have to propagate that change throughout the other projects. However, it isolates your code and allows you to write unit tests more easily as you can now focus on 5 classes instead of 500.
Another potential downside is, unfortunately PMD won't be able to detect if you duplicated code between your projects. At least I don't know how to do that yet.
I use this pattern (divide and conquer / refactor out replication) quite a bit to avoid duplicate code.