I’ve been working on a new application for some months now. It’s my first big JPA program, and is still in the early stages. However, the complexity of my JPA object tree is becoming a growing problem.
For instance I have an object tree of Users, who have Companies, Divisions, Related Divisions, Currencies, Local Currencies, Currency Exchange Rates. At lower levels, things are not so bad. For instance if I pull out Currencies, matters are easier to cope with. But for high level, tree topping elements like a list of Users, my object tree has become horrific.
Now, a small bug has slipped into the JPA object tree meaning an important join table is being overwritten by one of my entities. I hope I can find the bug, but what I’d like advice on, is how to avoid this rapidly burgeoning complexity.
Thanks!
My approach is:
- prefare unidirectional relations (eg. when loading role, you don’t usually need everyone with that role, and if you need it for user management, you can quary for it)
- prefare lazy loading, so you don’t manipulate huge graphs by accident
- if you don’t need entity as result of query, return non entity object (via select new).
- JPA is not replacement for good analysis (don’t just load object and traverse it, know what you need and load it)
- try to structure your objects in way where there is no object from which it is possible to get anywhere. instead of A <- B -> C use A -> B <- C. Information for queriing is there, but object graph is broken into parts, so you have complexity closer to sum of parts than multiplication of parts.
- make cleer divide between code in which entities are live and where changes does not automaticaly go into database.
This isn’t really a direct answer, but you might consider skipping complex object hierarchies altogether and just do straight SQL in the more complex cases.
I wrote a simple ORM called Norm because I didn’t want to incur all of the overhead of JPA. The theory is that you do the dead minimum necessary to get data in and out of the database. If your ORM can’t handle what you need to do, do it in SQL.
You could try using lazy loading of the related objects (Companies, Division, etc.). In your business layer, retrieve the related objects only if you require them. By default they will be null and save you heap space. If lazy loading becomes too complex (it usually does because of even more annotations and configurations), you can use indirect references.
So the User object would look like:
public class User{
Integer id;
Integer companyId;
Integer divisionId;
//usual getters and setters
//this is not a getter - notice the different in method name
public Company fetchUserCompany(){
//DAO call to retrieve Company by companyId defined in the User object
}
}
In practice this approach makes managing complex hierarchies very simple and you can safely retrieve a large list of User objects without worrying about heap space. It’s not purely ‘object oriented’ though. Bugs are easier to find since your UserDAO will only retrieve small User objects. In case you need the related objects the logic will be delegated to CompanyDAO.
In my experience I have seen that if the hierarchy is not very deep lazy loading is ok and easy to maintain, however in your case, you might be better off with the second approach.